Re: [Gnu-arch-users] [MERGE-REQUEST]: segfault using variable length argument list of rel_add_records()

[Robert Collins]

On Wed, 2005-04-06 at 18:45 -0500, Matthew Dempsky wrote:
> On Wed, 2005-04-06 at 10:48 +0200, Wolfgang Treutterer E1 wrote:
> > I could figure out that the segfault occurred in the second call to
> > va_arg(rp, rel_record) and the corresponding argument was the concluding
> > 0. Obviously the compiler could not interpret the zero as rel_record
> > type. The same observation applied to the other segfaults.
> 
> Hm, are you on a 64-bit system?

Probably. I've fixed similar bugs before :|

> > There is a simple solution: replace the 0 in the calling function by
> > rel_record_nil so that the compiler knows about the intended type when
> > building the argument list.
> > However, the function rel_add_record is widely used by other routines in
> > libarch, libfsutils and libawk. Thus there are quite a lot locations to 
> > patch. After fixing all occurences no more segfaults occurred.
> 
> This seems like an appropriate fix.  Your patch doesn't apply cleanly
> against Tom's tla-1.3.2 branch though, but it seems like a short perl
> script can redo the changes on any tree.
> 
> Does gcc have any features for warning for things like this?  There
> should be an option to specify that the varargs list will all be of the
> same type, and give a warning if any of them aren't being pushed onto
> the stack as that type.

That would break varargs (think va_printf). The problem is usually just
correct use of types - 0 != NULL. libarch has a bad idiom of using 0
where NULL is the appropriate type.

Rob

signature.asc
Description: This is a digitally signed message part