Objective Caml's Unix libraries

Objective Caml's Unix libraries

[Pawel Wojciechowski]

It seems to me that in the interface file unix.mli (from the directory
otherlibs/unix of the Objective Caml release 1.03), one line should be
amended. Instead of 

(*** Basic file input/output *)

type file_descr

there should be:

(*** Basic file input/output *)

type file_descr = int 

This allowed me to avoid some problems when using file descriptors 
(I recently signalled my problem on the mailing list).

File descriptors are integers indeed. On the other hand, there is 
a correct definition of this type (ie as above) in the main file unix.ml,
so everything should be ok (or I am wrong?). Unfortunately without that 
small amendment in the library files, I couldn't compile my program
without an error: "This expression has type int but is here used with 
type Unix.file_descr"

cheers,

Pawel

Re: Objective Caml's Unix libraries

[Xavier Leroy]

> It seems to me that in the interface file unix.mli (from the directory
> otherlibs/unix of the Objective Caml release 1.03), one line should be
> amended. Instead of 
> 
> type file_descr
> 
> there should be:
> 
> type file_descr = int 

No. File descriptors are an abstract type in the Unix library, and
this is a conscious decision. An abstract type is a type that can only
be manipulated using the operations given by its implementation
module. In the case of the Unix library, this means that the only way
to obtain a file descriptor is through the constants stdin, stdout,
stderr, or the operations open, pipe, accept, ... One of the benefits
is that typing will catch many stupid errors, such as confusing the
"file descriptor" and the "length" arguments to "read".

> File descriptors are integers indeed. 

That's what C programming lets you believe, but they are not. It does
not make sense to add or multiply two file descriptors, for instance.

> This allowed me to avoid some problems when using file descriptors 
> (I recently signalled my problem on the mailing list).

I have doubts that what you were trying to do (pass file
descriptors to an exec'd program by giving their numbers as
command-line arguments) is 100% POSIX conformant.

At any rate, the only way to pass file descriptors to an exec'd
program within the Unix library is to map them using dup2 to stdin,
stdout or stderr.

I agree it's an unpleasant constraint, but it's a small price to pay
for the additional safety brought by having abstract file descriptors.

Regards,

- Xavier Leroy

Re: Objective Caml's Unix libraries

[Bruno.Verlyck]

[ english summary at the end ]
   From: Xavier Leroy <Xavier.Leroy@inria.fr>
   Date: Wed, 12 Mar 1997 10:41:17 +0100 (MET)

   No.  File descriptors are an abstract type in the Unix library, and
   this is a conscious decision.

   > File descriptors are integers indeed.

   That's what C programming lets you believe, but they are not.  It
   does not make sense to add or multiply two file descriptors, for
   instance.
Tout ceci est indiscutable.

   At any rate, the only way to pass file descriptors to an exec'd
   program within the Unix library is to map them using dup2 to stdin,
   stdout or stderr.

   I agree it's an unpleasant constraint, but it's a small price to
   pay for the additional safety brought by having abstract file
   descriptors.

Le problème est que C suinte de partout.  Si je devais implémenter
/bin/sh en Caml, la librairie Unix ne me permettrait pas de traiter la
redirection <&3.  Une fonction fileno : filedesc -> int résoudrait ce
problème (et celui de Pawel.Wojciechowski), mais je ne vois pas
comment traiter >&3 (je n'ai réfléchi que 5 minutes).

Bon, l'interface de /bin/sh est de niveau scandaleusement bas, il y a
(n'en doutons pas) moyen d'en concevoir une meilleure.  Encore faut-il
pouvoir (avoir le droit de) changer les specs...  Et là, on n'a pas
nécessairement le choix du prix à payer.  Ré-écrire une librairie Unix
modifiée ? (il faudrait l'appeler Shell :-)

In english: Xavier's arguments are very strong.  But within them (and
the Unix library), I can't write a /bin/sh clone, because of >&3
(here, and for Pawel.Wojciechowski, it would be enough to add a fun
fileno : filedesc -> int, like the stdio macro) and <&3 -- but I
thought about it for only 5 min.

My point is that you can try to change the specs, but you have to be
allowed to...

Bruno.

Disclaimer: I don't need anything more than the Unix library.

Re: Objective Caml's Unix libraries

[Alexandre Frey]

Bruno,

> In english: Xavier's arguments are very strong.  But within them (and
> the Unix library), I can't write a /bin/sh clone, because of >&3
> (here, and for Pawel.Wojciechowski, it would be enough to add a fun
> fileno : filedesc -> int, like the stdio macro) and <&3 -- but I
> thought about it for only 5 min.
As a hack, you can always write this:
let fileno (fd: file_descr): int = (Obj.magic fd)

But of course, you loose the safety of the abstract `file_descr' type.

--
Alexandre.