From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Pawel.Wojciechowski@cl.cam.ac.uk (Pawel Wojciechowski)
Cc: caml-list@inria.fr
Subject: Re: Objective Caml's Unix libraries
Date: Wed, 12 Mar 1997 10:41:17 +0100 (MET) [thread overview]
Message-ID: <199703120941.KAA08613@pauillac.inria.fr> (raw)
In-Reply-To: <E0w4aby-0001c1-00@heaton.cl.cam.ac.uk> from Pawel Wojciechowski at "Mar 11, 97 11:05:37 pm"
> 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
next prev parent reply other threads:[~1997-03-12 16:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-03-11 23:05 Pawel Wojciechowski
1997-03-12 9:41 ` Xavier Leroy [this message]
1997-03-12 19:50 ` Bruno.Verlyck
1997-03-13 9:52 ` Alexandre Frey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199703120941.KAA08613@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=Pawel.Wojciechowski@cl.cam.ac.uk \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox