[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [MERGE-REQUEST]: segfault using variable length arg
From: |
Robert Collins |
Subject: |
Re: [Gnu-arch-users] [MERGE-REQUEST]: segfault using variable length argument list of rel_add_records() |
Date: |
Thu, 07 Apr 2005 11:28:45 +1000 |
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