Re: [RFC][PATCH v2] Initial support for C11 Annex K Bounds checking functions

[Paul Eggert <eggert at cs dot ucla dot edu>]

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.