stdarg: va_list pass by value?

[Mark Hall]

In article <14628 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>In article <136196 at pyramid.pyramid.com> markhall at pyrps5.pyramid.com (Mark Hall) writes:
>>Since the standard explicitly calls out the indeterminacy
>>of passing AP objects as arguments, shouldn't it also call out the 
>>indeterminacy of assigning AP objects?
>
>It doesn't have to; since va_list may be an array type, a strictly-
>conforming program must not attempt to copy by in an assignment
>expression.  This leaves open the question whether or not one could
>memcpy() it, but my advice is to not try such elaborate hackery.

Aha!  That same argument could be applied to the indeterminacy of
passing the va_list as an argument.  From what you say, the user
should also have known that the va_list type could have been
an array, and so the state of the va_list object on return from
the function call would be indeterminate by direct implication.  Therefore
it is redundant for the standard to specifically call out the indeterminacy
of passing a va_list object as an argument.  So much for language-lawering 
the issue.

My personal objection is that, in the big scheme of things, there isn't
anything available to assist the poor programmer in writing a
"maximally portable program".  Had the standard called out a constraint
on the operations allowable on a va_list object (my tiny little case in
point), then I wouldn't (already!) be seeing so many non-conforming 3rd
party programs which were not "caught" by the compiler on which they
were developed.  Man, customers look at you funny when you tell them
their program isn't "conforming".  They tend to suspect that XYZ's
compiler is "better", even though your's did the harder job.  You don't
win marketing points by having the strictest compiler around.

-Mark Hall (smart mailer): markhall at pyrps5.pyramid.com
	   (uucp paths): {ames|decwrl|sun|seismo}!pyramid!markhall