va_list structure passing as argument

[Sean McNeil]

On Tue, 2004-08-24 at 02:20, Peter Wemm wrote:
> On Monday 23 August 2004 11:20 pm, Sean McNeil wrote:
> > I'm looking at a problem I have on the amd64 with bsdtar. 
> > Essentially, you get a core dump if you try to run the following:
> >
> > tar zxvvf nonexistent.tar.gz
> >
> > I've tracked it down to an issue where the ap is getting changed as a
> > side-effect of calling __vfprintf.  It looks like this is happening
> > because the va_list structure is being passed by reference.  The
> > va_list structure on amd64 is 24 bytes.  I'm guessing that it is 16
> > bytes or less for i386.  It has been a while since I've looked at the
> > macro that determines when a structure is passed by reference or
> > value.  Does anyone know what that is?  I'm guessing that 24 passes
> > that cutoff but 16 does not and that is why I see this bug on amd64
> > and not i386.
> 
> Yes, its an external value.  Consider it a pointer.  It is the same on 
> both ppc and amd64.
> 
> The problem is that vfprintf  "consumes" the values and advances the 
> counters in the structure.  (The argument passing ABI is very complex)
> 
> What you need to do is this:
> myfunc(va_list ap)
> {
> 	va_list apcopy;
> 
> 	va_copy(apcopy, ap);
> 	vprintf(stuff, ap1);
> 	va_copy(apcopy, ap);
> 	do_stuff_with(ap1);
> }
> etc.  Using va_copy is "correct" for all our platforms, but neglecting 
> to use it is only fatal for amd64 and ppc.
> 
> Does that make sense?

Makes sense and is what I tried originally.  I figured this wasn't
correct, however, as it means that a side-effect of the call is
allowable.  What you are indicating is that it is allowable and
expected.  The problem is, the side-effect will only happen on ppc and
amd64 since i386 will pass the va_list by value.

Thanks,
Sean