🚀 go-pugleaf

In article <4kdk5v$mn@solutions.solon.com>, seebs@solutions.solon.com (Peter Seebach) writes:
>	void foo(int bar, ...) {
>		va_list ap;
>		int i;
>		va_start(ap, bar);
>		for (i = 0; i < bar; ++i)
>			baz(&ap);
>		va_end(ap);
>	}
>	void baz(va_list *ap) { printf("%d\n", va_arg(*ap)); }
>is this legal?  If not, is there a compelling reason?

ANSI Classic section 4.8, page 123 lines 12 to 15:  "The object ap may be
passed as an argument to another function; if that function invokes the
va_arg macro with parameter ap, the value of ap in the calling function
is indeterminate and shall be passed to the va_end macro prior to any
further reference to ap."

The standard does not quite say that &ap may be passed, but let's try to
pretend that this was an editorial oversight and a TC will permit it.

After the first invocation of baz() returns, the value of ap in the
calling function is indeterminate.  ap can be passed to va_end, and I
think that &ap can probably be computed and passed around, but the value
of ap is just as indeterminate in the second invocation of baz() as it
was in main() between the two invocations.

What you really want is a TC to say that if &ap is passed then the value
of ap does not become indeterminate.  Ask your national representative to
propose this.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer

In article <4kkk50$h94@usenet.pa.dec.com> diamond@tbj.dec.com (Norman
Diamond) writes:

|> In article <4kdk5v$mn@solutions.solon.com>, seebs@solutions.solon.com (Peter Seebach) writes:
|> >	void foo(int bar, ...) {
|> >		va_list ap;
|> >		int i;
|> >		va_start(ap, bar);
|> >		for (i = 0; i < bar; ++i)
|> >			baz(&ap);
|> >		va_end(ap);
|> >	}
|> >	void baz(va_list *ap) { printf("%d\n", va_arg(*ap)); }
|> >is this legal?  If not, is there a compelling reason?

|> ANSI Classic section 4.8, page 123 lines 12 to 15:  "The object ap may be
|> passed as an argument to another function; if that function invokes the
|> va_arg macro with parameter ap, the value of ap in the calling function
|> is indeterminate and shall be passed to the va_end macro prior to any
|> further reference to ap."

|> The standard does not quite say that &ap may be passed, but let's try to
|> pretend that this was an editorial oversight and a TC will permit it.

I'm not sure that it was an editorial oversight.  As currently defined,
I *think* that va_list could be an array type.  (It certainly was on
many pre-ISO implementations, and I can see nothing in the wording of
the current standard to prevent it.)

If va_list is an array type, then va_arg will be written using the
implicit conversion to pointer, and passing the ap object will in fact
pass the pointer.

|> After the first invocation of baz() returns, the value of ap in the
|> calling function is indeterminate.  ap can be passed to va_end, and I
|> think that &ap can probably be computed and passed around, but the value
|> of ap is just as indeterminate in the second invocation of baz() as it
|> was in main() between the two invocations.

I suspect that one of the reasons why the value of ap is indeterminate
is that the standard wishes to make it unspecified whether pass by
reference (as with an array type) or pass by value are being used.

|> What you really want is a TC to say that if &ap is passed then the value
|> of ap does not become indeterminate.  Ask your national representative to
|> propose this.

IMHO, *if* it is legal to pass `&ap' (or more generally, if the results
of the expression `&ap' are defined to have any reasonable value), then
I think that passing them as a parameter must implicitly work.  However,
I'm not convinced that this expression is legal.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung