Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!hao!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Questions on vsprintf(), vsscanf(), stdarg.h, varargs.h
Message-ID: <6187@brl-smoke.ARPA>
Date: Tue, 28-Jul-87 14:12:09 EDT
Article-I.D.: brl-smok.6187
Posted: Tue Jul 28 14:12:09 1987
Date-Received: Thu, 30-Jul-87 00:53:24 EDT
References: <2545@hoptoad.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 58

In article <2545@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>... there is apparently no vsscanf().  If not, why not?

I suspect mainly because the scanf() family are unsafe functions that
are only provided because so much existing code already uses them.
There is little interest in adding to that family.

>In the draft C standard, it specifies:
>	"The type declared is va_list which is an array type...
>	The variable ap may be passed as an argument to another function."
>(ap refers to the parameter declared as va_list.)  If passed to another
>function, the array will be converted to a pointer, which presumably
>means that calls to va_arg in the subroutine would also advance
>the argument pointer, as documented in SunOS.  The standard should
>specify this behaviour rather than leaving it to be inferred.

The argument walker is stored in the array in the parent routine.
The standard does not purport to be a tutorial.  Generally it adds
explanations only where it is felt there are grounds for confusion
or misinterpretation.  The whole point of requiring va_list to be an
array type (and no other) is to make clear the exact semantics to
be expected of ap.  It would perhaps be appropriate to have words
to this effect in the Rationale, but the Standard is unambiguous on
this point.

>(Actually the standard should standardize  rather than a newly
>invented, incompatible construction.)

That is uncalled for.  I assure you that X3J11 does not go about
changing things without good reason.  They did start with ,
but found that it was simply not suitable for the more rigorous ", ..."
approach to variable argument lists, as well as to accommodate unusual
CPU architectures.  It is important to realize that it is only under a
simple, uniform implementation such as most VAX and MC68000 C systems
that the new X3J11 mechanisms duplicate existing functionality with no
substantial change to the underlying mechanisms.  In the more general
setting, a variable-argument function is a NEW and DIFFERENT beast than
what you have seen before.  It may be implemented quite differently from
a fixed-argument function.  The  mechanism is specifically
designed to support this new and different beast, which in turn was
introduced out of necessity (under some circumstances) to let the
implementation know about the different essential nature of varargs
functions.   went through many design iterations before
stabilizing in the form it now has (very slightly amended on 15-May-1987).

I suspect that C implementations on the more trivial architectures will
provide both  and , but the v*printf() functions
have to know what type they're getting for ap, so they will no longer
be usable with  va_list variables.  The persistence of the
names va_* reflects the evolution from  and is perhaps
unfortunate at this point; for a while X3J11 was hoping to be able to
guarantee full compatibility between the two approaches.

Disclaimer:  This is not to be construed as an official X3J11 response.
Send public comments to Tom Plum; there is still some (slim) chance that
the committee will consider them before the next public review even
though it is way past the official comment period for the last public
draft.