Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!hc!beta!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Function prototypes versus open()
Message-ID: <5927@brl-smoke.ARPA>
Date: Mon, 1-Jun-87 18:33:33 EDT
Article-I.D.: brl-smok.5927
Posted: Mon Jun  1 18:33:33 1987
Date-Received: Wed, 3-Jun-87 03:31:04 EDT
References: <18346@ucbvax.BERKELEY.EDU> <8042@utzoo.UUCP> <2210@hoptoad.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <2210@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>The standard Unix open() call can take either two or three parameters,
>but you are not required to #include any header files to use it.  Now,
>if you are using the third operand, you will be including <sys/file.h>
>to get O_CREAT, but if not, it seems to be perfectly acceptable to use
>a small integer constant as the second operand.

I don't understand the point you're trying to make.  open() is not an
ANSI C function at all.  POSIX requires that you #include three headers
(which does seem like two too many; <stat.h> should not be required) for
portable invocation of open().  (<sys/file.h> is NOT one of these.)
Non-POSIX UNIX-like systems are free to do whatever they please.

The only way for an application programmer to correctly, portably code
his own IMPLEMENTATION of open() in ANSI C would be to use the <stdarg.h>
mechanism; however, implementors of ANSI C can implement it any way they
choose -- for most existing systems the implementation would be unchanged.
In particular, for most existing systems, code that invokes open() without
including <fcntl.h> would continue to work, but portability cannot be
assured (which is simply a fact of life).