From: Xavier Leroy <Xavier.Leroy@inria.fr>
Message-Id: <199703120941.KAA08613@pauillac.inria.fr>
Subject: Re: Objective Caml's Unix libraries
In-Reply-To: <E0w4aby-0001c1-00@heaton.cl.cam.ac.uk> from Pawel Wojciechowski at "Mar 11, 97 11:05:37 pm"
To: Pawel.Wojciechowski@cl.cam.ac.uk (Pawel Wojciechowski)
Date: Wed, 12 Mar 1997 10:41:17 +0100 (MET)
> 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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:09 MET