This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implementation of C11 Bounds-checking interfaces
On Wed, 31 Oct 2012, Carlos O'Donell wrote:
> What was the reason given for not wanting to integrate this work with glibc?
>
> Do you have a reference to the public discussion?
>
> My personal inclination is to attempt to include this functionality in
> glibc, but I don't have that much experience with the functions in
> Annex K.
I previously commented at
<http://sourceware.org/ml/libc-alpha/2012-02/msg00297.html> (see also the
rest of that thread).
It would be good to know what issues were encountered in implementing the
standard requirements outside of glibc, since that's the main factor I
think should determine the best place for these functions.
* I'd think the K.3.1.1 paragraph 4 requirement ("Within a preprocessing
translation unit, __STDC_WANT_LIB_EXT1__ shall be defined identically for
all inclusions of any headers from subclause K.3. If
__STDC_WANT_LIB_EXT1__ is defined differently for any such inclusion, the
implementation shall issue a diagnostic as if a preprocessor error
directive were used.") may need a compiler feature (a GCC pragma to say
that a header is using a standard feature test macro like this) to be met
fully.
* Although you can probably meet the header requirements using
#include_next, and may be able to predefine __STDC_LIB_EXT1__ by providing
your own stdc-predef.h that uses #include_next, doing so would certainly
be simpler with closer library integration.
* It's the printf/scanf requirements that seem hardest to meet separately
(hence this implementation having a modified copy of thousands of lines of
scanf code, which certainly isn't good practice for maintainability).
* As already noted, there are namespace issues with implementing outside
of glibc, since the functions should only use implementation-namespace
external names and C11-namespace (including Annex K-namespace, of course)
external names, not POSIX or glibc names that for C11 are in the user
namespace.
Given the above I suspect there may be advantages in implementing in glibc
- though possibly in a separate library from libc.so that glibc also
installs, rather than directly in libc.so. (I don't know if there is any
existing practice from other POSIX systems regarding what library to put
these functions in.) If a separate library built by glibc is used,
libc.so could export any non-C11-namespace symbols required with __* names
at GLIBC_PRIVATE symbol version.
--
Joseph S. Myers
joseph@codesourcery.com