This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use 1U everywhere in elf/elf.h.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Petr Machata <pmachata at redhat 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: Tue, 24 Mar 2015 21:23:55 +0000
- 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>
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