Re: Implementation of C11 Bounds-checking interfaces

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Oct 31, 2012 at 05:27:43PM +0000, Joseph S. Myers wrote:
> 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.

I don't think so. This behavior is easily obtained with traditional
preprocessor conditionals.

However, I question whether conformance to this requirement is even
desirable. It can't break conforming programs to ignore it, and the
only reason to support these interfaces should be supporting the rare
program that needs them, not any abstract conformance goal, at least
in my opinion.

> * 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).

I think it's wrong to duplicate these functions, especially printf.
Instead, the format string can just be scanned/validated and the
string arguments checked not to be null pointers, then the work can be
passed on to the underlying vfprintf.

For scanf, I'm not sure what the best approach is.

> * 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.

If it's possible to implement these functions just in terms of
functions in the C11 namespace, I don't think it's an issue.

Rich