Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Another thing broken in ANSI C
Message-ID: <6979@brl-smoke.ARPA>
Date: 8 Jan 88 05:03:51 GMT
References: <3726@hoptoad.uucp> <6922@brl-smoke.ARPA> <1178@wjvax.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <1178@wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes:
>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.

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.

I use <varargs.h> a lot and have started using <stdarg.h> under control
of #if __STDC__, although I don't yet have an ANSI C compiler.  I don't
have any problems with this.