This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH v2] Initial support for C11 Annex K Bounds checking functions
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Ulrich Bayer <ubayer at sba-research dot org>, libc-alpha at sourceware dot org
- Date: Wed, 05 Jun 2013 18:13:08 -0700
- Subject: Re: [RFC][PATCH v2] Initial support for C11 Annex K Bounds checking functions
- References: <5102DBFD dot 4060103 at sba-research dot org> <513DE7A1 dot 8080501 at sba-research dot org> <Pine dot LNX dot 4 dot 64 dot 1305151554100 dot 15900 at digraph dot polyomino dot org dot uk> <51AF6406 dot 30201 at sba-research dot org> <Pine dot LNX dot 4 dot 64 dot 1306051643310 dot 14749 at digraph dot polyomino dot org dot uk> <51AFB0D1 dot 4010708 at cs dot ucla dot edu> <Pine dot LNX dot 4 dot 64 dot 1306052201280 dot 7769 at digraph dot polyomino dot org dot uk>
On 06/05/2013 03:07 PM, Joseph S. Myers wrote:
> That does indicate maybe using __STDC_WANT_LIB_EXT1__ || __USE_GNU in
> headers, instead of defining __STDC_WANT_LIB_EXT1__ in features.h.
That'd be better, yes.
I'm mildly inclined to suggest plain __STDC_WANT_LIB_EXT1__ as
something better yet, as it's simpler and may help in the future.
What do other C library implementations do here? That may help
us decide this issue.
>> Which brings up another point: the proposed implementation doesn't
>> support K.3.1.1 paragraph 4 -- shouldn't it?
>
> As previously discussed, that requires a new GCC feature
Sorry, I missed that discussion, but I don't see why a new GCC feature
is required. The intent of K.3.1.1 paragraph 4 is to allow a straightforward
implementation inside the usual multiple-protection guards.
If K.3.1.1 seems to imply otherwise, it's a bug in the standard.
7.1.2 paragraph 4 says that (except for NDEBUG) multiple
inclusions shall have the same effect as a single inclusion,
so it wouldn't make sense to interpret K.3.1.1 as requiring a
diagnostic because of a multiple inclusion.