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: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Ulrich Bayer <ubayer at sba-research dot org>, libc-alpha at sourceware dot org
- Date: Wed, 05 Jun 2013 14:42:41 -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>
On 06/05/13 10:03, Joseph S. Myers wrote:
> The only thing <features.h> can
> usefully do is to define __STDC_WANT_LIB_EXT1__ if the user defined
> _GNU_SOURCE (if we want these interfaces to be part of the _GNU_SOURCE API
> - and normally all interfaces do go in that API).
There are some good arguments against having <features.h> define
__STDC_WANT_LIB_EXT1__. Mainly, it has the wrong "feel":
__STDC_WANT_LIB_EXT1__ is intended to be a macro specified by
the application, not by the implementation. And there are
some more-technical objections. For example:
* It won't work with <stddef.h>, which is supplied
by the compiler, not by glibc, and whose behavior should
depend on __STDC_WANT_LIB_EXT1__.
* It could generate bogus diagnostics. If (say) <stdio.h>
defines __STDC_WANT_LIB_EXT1__, then K.3.1.1 paragraph 4
would require a diagnostic for this program:
#include <stddef.h>
#include <stdio.h>
#include <errno.h>
since __STDC_WANT_LIB_EXT1__ would be defined for <errno.h>
but not for <stddef.h>, and K.3.1.1 para 4 requires a diagnostic
for that usage.
Which brings up another point: the proposed implementation doesn't
support K.3.1.1 paragraph 4 -- shouldn't it?