Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

close_in twice does not raise an exception #3426

Closed
vicuna opened this issue Jul 14, 2002 · 5 comments
Closed

close_in twice does not raise an exception #3426

vicuna opened this issue Jul 14, 2002 · 5 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 14, 2002

Original bug ID: 1235
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Emmanuel Renieris
Version: 3.02-3.04+15
OS: Linux/Solaris
Submission from: miette.cs.brown.edu (128.148.38.66)

Typing in the following at the top level does not raise an exception. the manual
says it should.

let c= open_in "/dev/zero" in close_in c; close_in c;;

  • : unit = ()

This is true on a Linux debian testing 2.2.20, and on Solaris 7.
Our Ocaml is 3.02 on Solaris and 3.04 and 3.04_15 on the Linux boxes.

Of course, there's probably code out there that depends on it...

@vicuna
Copy link
Author

vicuna commented Jul 15, 2002

Comment author: administrator

Typing in the following at the top level does not raise an
exception. the manual says it should.

let c= open_in "/dev/zero" in close_in c; close_in c;;

  • : unit = ()

This point has been hotly debated among the Caml team, and I'm not
sure we've reached a consensus yet... There are cases where it is
convenient to ignore a "close" on an already closed descriptor,
e.g. the program closes stdout explicitly, and later the normal exit
procedure closes it again.

(Caml folks: what is the consensus? Should we fix the implementation
or the documentation?)

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 17, 2002

Comment author: administrator

Date: Mon, 15 Jul 2002 10:04:02 +0200 (MET DST)
From: xavier.leroy@inria.fr

Typing in the following at the top level does not raise an
exception. The manual says it should.

let c= open_in "/dev/zero" in close_in c; close_in c;;

  • : unit = ()
    This point has been hotly debated among the Caml team, and I'm not
    sure we've reached a consensus yet... There are cases where it is
    convenient to ignore a "close" on an already closed descriptor,
    e.g. the program closes stdout explicitly, and later the normal
    exit procedure closes it again.
    [ Non, il flushe seulement. ]

(Caml folks: what is the consensus? Should we fix the
implementation or the documentation?)
Au cas où je serais concerné: il me semble que le débat était de
savoir si on peut faire flush sans erreur sur un canal fermé (c'est le
seul où je me suis impliqué, en tous cas). Le consensus est qu'on
peut le faire. Si ça changeait, plusieurs endroits du code (dans la
distribution de Caml même) auraient à être modifiés (alourdis ?), et
seraient sans doute plus fragiles.

Pour close, traditionnellement, on peut le faire aussi. Par contre,
je ne pense pas (doigts croisés) que ça introduise des bogues (hors du
code utilisateur).

Bref, c'est plutôt un problème de compatibilité ascendante, il me
semble. Il n'y a plus qu'à décider si c'est avec le manuel ou le
code.

Bruno.

@vicuna
Copy link
Author

vicuna commented Jul 17, 2002

Comment author: administrator

Quelques informations supplémentaires, après relectures à droite et
gauche:

Date: Wed, 17 Jul 2002 14:48:27 +0200 (MET DST)
From: Bruno.Verlyck@inria.fr

Pour close, traditionnellement, on peut le faire aussi. Par
contre, je ne pense pas (doigts croisés) que ça introduise des
bogues (hors du code utilisateur).
Par contre, Cash s'appuie sur le comportement de Pervasives. Ça
simplifierait le close Cash qu'une exception soit levée (ses 16 lignes
repasseraient à 3); mais les 16 lignes sont écrites, donc ça n'est pas
une raison impérative.

Bref, c'est plutôt un problème de compatibilité ascendante, il me
semble. Il n'y a plus qu'à décider si c'est avec le manuel ou le
code.
Je pense que j'ai retrouvé l'histoire: quand a été ajouté le code pour
détecter la lecture ou écriture sur un canal fermé (ou plus tard, en
3.04, quand j'ai intégré mes modifications pour Cash), flush sur un
canal fermé provoquait une erreur, donc close_out aussi. Ça a été
documenté comme tel (en 3.04). Mais close_in ne faisait pas d'erreur
dans ce cas, bien que la mise à jour de la documentation le laissait
croire.

Maintenant que flush ne fait plus d'erreur, aucun des 2 close ne
correspond plus à la documentation. Et la question de compatibilité
ascendante est: compatible 3.04, ou avec les versions précédentes ?
Plus strict ou plus laxiste ?

Dernière note: si on fait plus strict, sur EBADF [il y a aussi EINTR
et EIO], il faudrait lever l'exception après avoir modifié la struct
channel, i.e.:

CAMLprim value caml_close_channel(value vchannel)
{
/* For output channels, must have flushed before /
struct channel * channel = Channel(vchannel);
close(channel->fd);
pas ici
channel->fd = -1;
/
Ensure that every read or write on the channel will cause an
immediate flush_partial or refill, thus raising a Sys_error
exception */
channel->curr = channel->max = channel->end;
mais ici
return Val_unit;
}

ceci car le close peut avoir été fait sur le fd directement
(modérément facile avec Unix, très simple avec Cash). Comme ça, les
I/O sur ce canal sont détectées dès ce moment.

Bruno.

@vicuna
Copy link
Author

vicuna commented Jul 18, 2002

Comment author: administrator

Updated documentation to match implementation. XL, 2002-07-18

@vicuna vicuna closed this as completed Jul 18, 2002
@vicuna
Copy link
Author

vicuna commented Jul 18, 2002

Comment author: administrator

Bref, c'est plutôt un problème de compatibilité ascendante, il me
semble. Il n'y a plus qu'à décider si c'est avec le manuel ou le
code.

Bon, j'ai corrigé le manuel pour documenter le comportement "laxiste"
de close_in et close_out.

  • Xavier

@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant