This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Joseph Myers <> writes:

> 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.

Agreed--I'm not sure how to address this, but we have a nice
re-tabulated elf.h version over there, which is useful for task at

> 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.

Would a test like this make more sense to you?

#define TEST_FITS(VALUE, NAME, TYPE, W)					\
  _Static_assert ((TYPE) (VALUE) == VALUE /*...*/);

Vast majority of constants in elf.h are signed integers, assertion on
__builtin_types_compatible_p would break for any unsigned field.  But
the constants are suitable for initializing the corresponding field.
E.g. consider:

#define ELFOSABI_NONE		0	/* UNIX System V ABI */

The corresponding field is an unsigned char, but the expression here is
a (signed) integer one.  But surely unsigned char blah = ELFOSABI_NONE
is OK and it shouldn't fail?

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]