Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <6912@brl-smoke.ARPA>
Date: 5 Jan 88 22:30:59 GMT
References: <4668@pyr.gatech.EDU> <495@xyzzy.UUCP> <9930@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 50

In article <9930@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <495@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>>In other words, give me some example of "existing C programs broken" by
>>the draft standard.  I'm not aware of any interesting cases.
><varargs.h> vs. <stdarg.h>: Both define `va_start', but the one in
><varargs.h> takes one parameter, while the one in <stdarg.h> takes two.

Actually, any existing program that uses <varargs.h> is "broken" with
respect to ANSI C in several ways, not the least of which is that there
is no <varargs.h> in ANSI C.  On some simpler implementations (e.g. VAX
4.3BSD), it would indeed have been possible to support code such as
	#include <varargs.h>	/* not ANSI */
	#include <stdarg.h>	/* not in existing code, of course */

	/* The following is my attempt to indicate "arbitrarily" choosing
	   a way to define the code for some function, call it "foo",
	   depending on whim.
	 */
	#if Random_Number_Generator() < 0.5	/* or whatever */
	/* ... define function "foo" the varargs way ... */
	#else
	/* ... define function "foo" the stdarg way ... */
	#endif
so long as the <stdarg.h> and <varargs.h> macro names did not conflict
(but as Chris notes, the two headers as they are now specified cannot
coexist like this).  However, some architectures were identified for
which the best approach to variable argument lists would require help
from the compiler, thus the ", ..." syntax in ANSI C.  In ANSI C, the
<stdarg.h> macros are to be used ONLY for functions declared with the
", ..." variadic notation.  Similarly, the reason for requiring an
"anchor" parameter (which is the visible difference in syntax between
the two va_start() specifications) is that it was believed that some
architectures practically required such an anchor in order to locate
their arguments in the va_arg() implementation.

Varargs itself simply didn't appear to be universal enough to adopt
unchanged for the ANSI C standard; otherwise it would have been.

In practice, code using <varargs.h> will have to be converted to use
<stdarg.h> if it is desired to guarantee portability among ANSI C
implementations.  In general, this is not quite an automatic
procedure, and since some programmer was expected to have to actually
look at the code to determine how to make the changes, the use of the
same names as traditional <varargs.h> macros/functions was not
considered to be a problem.

By the way, thanks to all those who responded to my request for
unusual varargs/stdarg implementations.  Your comments were helpful
when I checked that the proposed ANSI C <stdarg.h> specifications
were viable.  I believe that as they now stand they are as universal
as can be achieved using the general approach taken by varargs.