Re: [PATCH] Use 1U everywhere in elf/elf.h.

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 24 Mar 2015, Petr Machata wrote:

> > I mean I could use C++ and the associated RTTI to do the comparison at
> > runtime and thus produce a detailed analysis of the types.
> >
> > Is that what you're thinking too?
> 
> Would something like the following be acceptable?  It builds on
> known-elf.h/known-elf.awk that I've earlier today proposed for
> contribution to elfutils.
> 
> 	#include <elfutils/known-elf.h>

I don't think it's a good idea to depend on elfutils on the glibc host (or 
even on the build system).  Tests built for the host should avoid 
depending on headers other than kernel headers and those included in 
glibc.

If a 32-bit signed type were correct, then it would be correct to have 
((int) 0x80000000) (a negative value) as the value of this macro.  I don't 
see testing whether things fit in a certain number of bits as making 
sense.  It makes more sense to test the types of the macros, if we first 
establish what the correct type is.

Testing types does not need to involve C++ / RTTI.  You can just use 
typeof to do a compile-time test for type compatibility (whether through 
multiple declarations of the same identifier, or using 
__builtin_types_compatible_p).

So what's the correct type?  The obvious type is that of the sh_flags 
field, except that sh_flags has different types (Elf32_Word and 
Elf64_Xword) for 32-bit and 64-bit ELF, so clearly the type can't match 
for one of them.  32-bit unsigned seems appropriate to avoid bogus 
sign-extension in the 64-bit case when the high bit is set.

-- 
Joseph S. Myers
joseph@codesourcery.com