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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Ulrich Bayer <ubayer at sba-research dot org>, <libc-alpha at sourceware dot org>
- Date: Thu, 6 Jun 2013 11:53:09 +0000
- 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> <51AFE224 dot 2090207 at cs dot ucla dot edu>
On Wed, 5 Jun 2013, Paul Eggert wrote:
> 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.
It goes against the normal principle of _GNU_SOURCE enabling all APIs -
and so requires a special -D option when building the implementation of
the Annex K functions, which wouldn't otherwise be needed because of the
_GNU_SOURCE define in libc-symbols.h (of course __STDC_WANT_LIB_EXT1__
could be added to libc-symbols.h, but it doesn't seem that should be
necessary either).
> >> 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.
I consider the "same effect" as being for correct uses, not as any sort of
requirement to have multiple-inclusion guards. For example, I think
#include <stddef.h>
#define int float
#include <stddef.h>
is undefined. And I interpret the K.3.1.1 requirement as meaning that
including one header with a define to 1, and another with a define to 1L,
must be diagnosed (the semantics of a define with a value other than
literal 0 or 1 may be undefined, but I think a diagnostic is still
required there).
--
Joseph S. Myers
joseph@codesourcery.com