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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Petr Machata <pmachata at redhat dot com>
- Cc: 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, 01 Apr 2015 16:16:47 -0400
- 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 03/24/2015 05:03 PM, Petr Machata wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
>
>> On 03/06/2015 05:28 PM, Roland McGrath wrote:
>>>> I would like to write a test case for it, but I can't get anything to
>>>> trigger the original reported failure by readelf when running with
>>>> -fsanitize=undefined.
>>>>
>>>> Therefore I can't at present even get a reproducer nor write a regression
>>>> test, but I know what what we have for SHF_EXCLUDE is wrong.
>>>
>>> A regression test for a reported manifest issue is of course worthwhile.
>>> But I was talking about a generic test that verifies at compile time what
>>> the types actually are rather than some particular characteristic of behavior.
>>
>> How?
>>
>> 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.
Sure.
> The way this would catch the original bug is that GCC refuses to
> compile-time evaluate 1 << 31. I'm not sure, but it seems that's
> because it's UB--change it to 1U or 1L and GCC compile-time evaluates it
> happily. So the compilation would fail, indicating that 1 << 31 is not
> a compile-time constant.
>
> Porting back to C<11, the static assert can be emulated by the
> negative-sized char array thick. Then the likes of 1 << 31 that are not
> compile-time constants lead to actual calls to log2, which we catch as
> link errors. Not as nice as compile-time error, but also works.
>
> If C++ is acceptable, it should be easy to replace the __builtin_log2
> and _Static_assert with a bit of (portable, if C++98 is considered that)
> template metaprogramming.
Any of your solutions looks good to me.
The test itself can be C or C++.
The test can include the header and test whatever it wants.
We support gcc 4.6 or newer for building glibc, so if that works great.
Cheers,
Carlos.