Re: parsing variable arg lists via va_list pointers (any gurus here?)

[Peter Nilsson]

Jesse Ziser <d...@spam.diew rote:

void parse_half_of_a rg_list( va_list *args )
{
   ...
   foo_t x = va_arg( *args, foo_t );
   bar_t y = va_arg( *args, bar_t );
   ...
}
>
void superfunc( int a, ... )
{
   va_list args;
   va_start( args, a );
   parse_half_of_a rg_list( &args );
   parse_half_of_a rg_list( &args );
   va_end( args );
}
>
I haven't been able to find anything in any standard
that explicitly allows or prohibits this.

The detail in VARIABLE ARGUMENTS explicitly allows it.
Nothing prohibits it. Only va_start and va_end must
'be invoked in the function accepting varying number
of arguments.'

but there aren't many ways I can think of that
some devious library author could screw this up.

They might accidentally screw it up, but the semantics
seem pretty clear.

C99 introduced va_copy, but that was so that the
same list could be rescanned from a given point
without starting afresh with another va_start.

But it doesn't appear that you need to do that.

--
Peter

[Jesse Ziser]

Re: parsing variable arg lists via va_list pointers (any gurus here?)

Peter Nilsson wrote:

Jesse Ziser <d...@spam.diew rote:

>void parse_half_of_a rg_list( va_list *args )
>{
> ...
> foo_t x = va_arg( *args, foo_t );
> bar_t y = va_arg( *args, bar_t );
> ...
>}
>>
>void superfunc( int a, ... )
>{
> va_list args;
> va_start( args, a );
> parse_half_of_a rg_list( &args );
> parse_half_of_a rg_list( &args );
> va_end( args );
>}
>>
>I haven't been able to find anything in any standard
>that explicitly allows or prohibits this.

>
The detail in VARIABLE ARGUMENTS explicitly allows it.

Where? I cannot find any explicit mention of this.

Nothing prohibits it. Only va_start and va_end must
'be invoked in the function accepting varying number
of arguments.'

Right, but I was bothered by the paragraph that says:

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 .

>but there aren't many ways I can think of that
>some devious library author could screw this up.

>
They might accidentally screw it up, but the semantics
seem pretty clear.

Thanks for your opinion. I hope you're right.

[Peter Nilsson]

Re: parsing variable arg lists via va_list pointers (any gurus here?)

Jesse Ziser <d...@spam.diew rote:

Peter Nilsson wrote:

Jesse Ziser <d...@spam.diew rote:

void parse_half_of_a rg_list( va_list *args )
{
   ...
   foo_t x = va_arg( *args, foo_t );
   bar_t y = va_arg( *args, bar_t );
   ...
}
>
void superfunc( int a, ... )
{
   va_list args;
   va_start( args, a );
   parse_half_of_a rg_list( &args );
   parse_half_of_a rg_list( &args );
   va_end( args );
}
>
I haven't been able to find anything in any standard
that explicitly allows or prohibits this.

The detail in VARIABLE ARGUMENTS explicitly allows it.

>
Where?  I cannot find any explicit mention of this.

Everything in the description of the <stdarg.hheader s.
They determine the usage and semantics of the various
va_xxxx entities. AFAICS, the above code is rigourous.

Nothing prohibits it. Only va_start and va_end must
'be invoked in the function accepting varying number
of arguments.'

>
Right, but I was bothered by the paragraph that says:
>
The object ap may be passed as an argument to another
function;

But you're not passing that object, you're passing a
pointer to it.

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.

Consider an implementation where va_list is a
struct that includes a malloced pointer. The
pointer needs to be free-ed, hence the need to
call va_end(). Passing the struct to a function
is legal, but whilst the malloced memory will
be updated across va_arg invocations, the other
elements of the struct in the original function
will not be changed since the va_list was passed
by value.

That is the kind of sceneraio that clause deals
with.

--
Peter