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: Ulrich Bayer <ubayer at sba-research dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Thu, 06 Jun 2013 12:24:50 -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> <51AFE224 dot 2090207 at cs dot ucla dot edu> <Pine dot LNX dot 4 dot 64 dot 1306061145300 dot 28623 at digraph dot polyomino dot org dot uk> <51B097D4 dot 8020507 at sba-research dot org>
On 06/06/13 04:53, Joseph S. Myers wrote:
>> 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 -
_GNU_SOURCE is one principle, but another principle is compatibility
with existing practice. For example, clang's stddef.h uses the
equivalent of this test:
defined __STDC_WANT_LIB_EXT1__ && __STDC_WANT_LIB_EXT1__ >= 1
That is, one must explicitly ask for the Annex K interface to get it,
which is pretty close to what I suggested.
To be consistent with clang's stddef.h we could do what clang does.
I expect it to be common behavior on POSIXish platforms, as the Annex K
stuff has a foreign feel to it, and (as Rich mentioned) glibc already
has a better solution, namely _FORTIFY_SOURCE.
> I consider the "same effect" as being for correct uses, not as any sort of
> requirement to have multiple-inclusion guards.
Yes, the standard doesn't require multiple-inclusion guards; but it
allows them, they're common implementation practice, and surely it's
intended that this practice continue to be allowed.
> (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).
It's implausible that the standard would require magic preprocessor
features to enforce a routine sanity check. I doubt whether actual
implementations work that way. Even if this behavior
was intended, we can easily implement a common-sense approximation to that
intent, using features that any C compiler will have, and then
implement pedantic checking later (presumably only with GCC). But we
really should ask for clarification from the standardization committee
before embarking on any project requiring preprocessor magic, as
there's a reasonably serious doubt that the magic is required.