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

[Ulrich Bayer]

On 06.06.2013 13:53, Joseph S. Myers wrote:
> 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).

>From what I know Microsoft's Visual Studio makes the _s functions available 
by default. In fact, the compiler issues warnings if a traditional function 
(such as strcpy) is used. Embarcadero, according to their example on 
http://docwiki.embarcadero.com/RADStudio/XE4/en/Strcpy_s,_wcscpy_s, seems to make 
them available without any prior preprocessor definition of
__STDC_WANT_LIB_EXT1__ before as well. 

Another question that comes to my mind is what happens in case 
__STDC_WANT_LIB_EXT1__ is neither 0 (user explicitly disables 
Annex K functions) nor 1 (user wants it). 

case a) __STDC_WANT_LIB_EXT1__ is defined but empty
I would find it counter-intuitive if a user could not write:
#define __STDC_WANT_LIB_EXT1__ 
instead of the longer 
#define __STDC_WANT_LIB_EXT1__ 1

case b) __STDC_WANT_LIB_EXT1__ is defined and neither empty, nor 0, nor 1
e.g. it's 2. This might be used to indicate a later version of the Annex K 
standard. Not sure what to do in this case.

What do you think?