This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use 1U everywhere in elf/elf.h.
- From: Petr Machata <pmachata at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Wed, 25 Mar 2015 14:30:48 +0100
- Subject: Re: [PATCH] Use 1U everywhere in elf/elf.h.
- Authentication-results: sourceware.org; auth=none
- References: <54F9E0CE dot 8070303 at redhat dot com> <20150306180147 dot 7EA492C3B32 at topped-with-meat dot com> <54FA28D8 dot 1080209 at redhat dot com> <20150306222818 dot 643092C3B39 at topped-with-meat dot com> <54FB4511 dot 2020008 at redhat dot com> <87d23ynm4r dot fsf at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1503242114280 dot 16467 at digraph dot polyomino dot org dot uk>
Joseph Myers <email@example.com> 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
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.
#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
> 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.