Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!hoptoad!gnu
From: gnu@hoptoad.UUCP
Newsgroups: comp.lang.c
Subject: Re: Function prototypes versus open()
Message-ID: <2242@hoptoad.uucp>
Date: Thu, 4-Jun-87 03:36:05 EDT
Article-I.D.: hoptoad.2242
Posted: Thu Jun  4 03:36:05 1987
Date-Received: Sat, 6-Jun-87 05:49:49 EDT
References: <18346@ucbvax.BERKELEY.EDU> <8042@utzoo.UUCP> <2210@hoptoad.uucp> <5927@brl-smoke.ARPA>
Organization: Nebula Consultants in San Francisco
Lines: 55

Several people didn't understand what I was saying, so let me try again.
This is strictly an ANSI C issue; there is no interaction with POSIX.

Let's suppose that someone writes a compiler such that if a function is
not declared with (...) then it cannot be called with a variable number
of arguments.  In other words, if the function is not declared at all,
it can't take a varying number of arguments.  If the function is
declared the old way, e.g. "int open();" it also will not work.  You
have to declare it as e.g. "int open(...);" for this compiler to pass
the arguments properly.  This is a valid way to write a compiler,
according to ANSI C.

This might occur in a machine with overlapping register windows, such
as a Pyramid or various RISC machines.  Typically, arguments would be
passed in registers, but for calls to vararg functions, they would get
pushed on a stack, or an argument count passed in secretly, or some
such.

If such a compiler was ever used to compile a Unix program, trouble
would arise.  Unix programs traditionally don't #include anything
when they are going to use the open() call, so there is no include file
that could declare "int open(...);" for them.  If the user calls open()
with two arguments, without having declared the "open" function in any
way, the compiler must assume that it is a two-argument function,
since all variable-argument functions MUST be declared with "...".
Sez so right in the standard.

Remember, the compiler has to know which kind of function it is --
fixed-args or variable-args, since it implements parameter passing
differently for the two kinds.  When it passes these two arguments to
the open() library routine, the arguments will be in the wrong place,
because the open() library routine will have to be written to assume
variable arguments, since indeed open() can be called with a variable
number of arguments.  In fact, another module of the same source
program could call open() with three arguments.

This means that such a compiler could not be compatibly used on a Unix
system, even though it meets all the requirements of the ANSI C standard,
and indeed BECAUSE it ENFORCES some of the requirements of the ANSI C
standard.

I can see a few possible ways around this but they all involve making
the varargs interface pass arguments compatibly with the non-varargs
interface, or massive kludgery (recognize the string "open"; bring in
different libraries at link time; append the argument count to the 
names of fixed-arg functions; and similar rot).  If implementations
are going to be forced to pass arguments compatibly, the standard might
as well not restrict users to declaring all their varargs functions, and
should not encourage implementors to require it.

How do the Pyramid and MIPS compilers handle open() calls now?
-- 
Copyright 1987 John Gilmore; you may redistribute only if your recipients may.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu