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
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
