This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]