Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!tektronix!teklds!copper!stevesu
From: stevesu@copper.UUCP
Newsgroups: comp.lang.c
Subject: Re: Function prototypes versus open()
Message-ID: <1125@copper.TEK.COM>
Date: Sat, 13-Jun-87 18:52:01 EDT
Article-I.D.: copper.1125
Posted: Sat Jun 13 18:52:01 1987
Date-Received: Sun, 14-Jun-87 18:37:43 EDT
References: <18346@ucbvax.BERKELEY.EDU> <8042@utzoo.UUCP> <2210@hoptoad.uucp> <514@haddock.UUCP>
Organization: Tektronix Inc., Beaverton, Or.
Lines: 44

In article <514@haddock.UUCP>, karl@haddock.UUCP (Karl Heuer) writes:
> I think the addition of a third argument to open() was a really dumb
> move by AT&T.  This causes open() to be weakly variadic without need,
> and creates nonportable code since neither BSD nor Research UNIX has
> implemented this, to the best of my knowledge.

I really like the new, optional third argument to open().  It is
one of the few cases I know of in the Unix world in which a truly
new feature was added to an existing call in a backwards-compatible
way.  I first came across it in 4.xBSD (which does have it, by
the way) and was astonished that Berkeley had done something that
clever, since backwards-incompatibility is usually their battle
cry.  (I now know that it was implemented first at AT&T, and
emulated in BSD.)

Of course, code using it is less portable, but then so is code
using any new feature.  I only use a three-argument open when I
need its extra semantics, otherwise I use old-fashioned creat()
and/or two-argument open().

I will grant that functions with variable numbers of arguments
are a problem.  However, backwards incompatibility is a bigger
problem.  I insist that extensions be made in a backwards
compatible way, to avoid breaking existing code.  If a case can
be made for adding functionality to an existing call (rather than
adding a new call) and if the new functionality requires new
arguments, then varargs is the only way to go.  The optional
third argument to open is specified correctly, in that its
presence is signaled by a previous argument (the O_CREAT bit in
the second argument).  There is no need for the callee to
discover the number of arguments in the stack frame, which can be
done reliably on the VAX but on few other architectures.

Implementors of architectures with register or other non-stack
argument passing mechanisms will simply have to solve the varargs
problem (as long as the language provides sufficient information,
as a function prototype does.)  You need varargs for printf(),
which I think everybody agrees is an appropriate and useful
application of varargs, so why not use it for open() as well,
even if the case for the optional argument is a little less
strong?

                                           Steve Summit
                                           stevesu@copper.tek.com


Brought to you by Super Global Mega Corp .com