Version française
Home     About     Download     Resources     Contact us    
Browse thread
Objective Caml's Unix libraries
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: Objective Caml's Unix libraries
> 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