Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbvax!unisoft!cerebus!wjvax!brett
From: brett@wjvax.UUCP (Brett Galloway)
Newsgroups: comp.lang.c
Subject: Re: Another thing broken in ANSI C
Message-ID: <1178@wjvax.UUCP>
Date: 7 Jan 88 02:20:48 GMT
References: <3726@hoptoad.uucp> <6922@brl-smoke.ARPA>
Reply-To: brett@wjvax.UUCP (Brett Galloway)
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 37

In article <6922@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In fact, many implementations will probably have the same interface for
>variadic functions as they have been using to date for all functions,
>so this is a non-issue for those implementations.  The ones that really
>needed the variadic indicator assist will probably be glad to have it.
>My experience has been that mighty few users of <varargs.h> have done
>it right (i.e. strictly according to the rules) anyway..

Actually, it is not quite fair to dismiss all code that currently uses
UNIX-style varargs by saying "mighty few users of <varargs.h> have done
it right."  As you might already have inferred from my interest in the matter,
I have made great use of <varargs.h> on a UNIX 4.2BSD system, and I believe
that I have done so correctly, at least consistent with varargs(3).

The fact is that the current form of the standard breaks the programs in
which I have used <varargs.h>.  I can see why the semantics of <stdarg.h> might
have to change to accommodate more architectures.  What I can't see is why it
was necessary to break code which works on architectures in which varargs(3)
is adequate.  I am not convinced why variable arguments should require
function prototyping (actually, the ... notation).  It seems to me that the
va_alist macro could be defined to supply that if required.  In that case, the
argument that name conflicts between <varargs.h> and <stdarg.h> are
excusable because the user would have to re-code anyhow become less
compelling.  Could an expert explain to me why it was not possible to
define <stdarg.h> with different names and to *permit* <varargs.h> to be
defined *in addition* on architectures on which its semantics could be
supported, either based on top of <stdarg.h> or independent of it?

I can hardly expect my existing code to port to architectures on which the
semantics of <varargs.h> are unsupportable (not that I am convinced that that
is an exceptionally important limitation).  However, I think I can expect my
existing code to work on architectures on which it currently works.

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