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: Ulrich Bayer <ubayer at sba-research dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, <libc-alpha at sourceware dot org>
- Date: Thu, 6 Jun 2013 16:08:20 +0200
- 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>
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?