Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!imagen!qubix!wjvax!brett
From: brett@wjvax.UUCP (Brett Galloway)
Newsgroups: comp.lang.c
Subject: Re: Another thing broken in ANSI C
Message-ID: <1183@wjvax.UUCP>
Date: 11 Jan 88 00:59:36 GMT
References: <3726@hoptoad.uucp> <6922@brl-smoke.ARPA> <1178@wjvax.UUCP> <6979@brl-smoke.ARPA>
Reply-To: brett@wjvax.UUCP (Brett Galloway)
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 44

In article <6979@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <1178@wjvax.UUCP> brett@wjvax.UUCP I wrote:
>>The fact is that the current form of the standard breaks the programs in
>>which I have used <varargs.h>.
>People bandy the term "breaks code" around too freely.

Hmmm.  <stdarg.h> is not compatible with <varargs.h>.  Further, I
understood that I had no guarantee of <varargs.h> semantics being
provided; in fact, the name spaces of <stdarg.h> and <varargs.h>
conflict.

>It is highly likely that when your system vendor switches over to an
>ANSI conforming C compiler, it will also provide <varargs.h> which
>will continue to work the same way it currently does.  Only a few
>special architectures really had trouble with implementing <varargs.h>,
>and only they are likely to use a different calling sequence for
>variadic functions.  Even some of these can still whip up a <varargs.h>
>that will work, although in a different manner from before.
>The only constraint will be that you cannot readily mix use of
><stdarg.h> and <varargs.h> in the same translation unit (source file).
>Since you're not currently doing this, it is not an issue until you
>have to modify your code to use <stdarg.h>, for example in order to
>get it to run on an architecture that doesn't support <varargs.h>.
>When that situation arises, you'll have to fix all your uses of
><varargs.h> anyway, which means there still won't be a conflict.

That's what I was asking.  I understood that <stdarg.h> was to *replace*
<varargs.h>; <varargs.h> would no longer be supported because of the name
conflicts between it and <stdarg.h>.  I thought one of the goals of
ANSI C was to regularize the name space.  If a vendor provides a
<varargs.h> which retains its semantics but conflicts with <stdarg.h>
(as it must, as <stdarg.h> names conflict with <varargs.h>), then neither
that include file nor my code which uses it is ANSI C conformant.  Worse,
it is a kludge.

All I asked was to take this one teeny step further -- change the names
in <stdarg.h> and require <varargs.h> also to be defined with its
current semantics where possible.  No conflict.  Maximum portability.
Everybody's happy.

-- 
-------------
Brett D. Galloway
{ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett