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, Oct 31, 2012 at 06:16:45PM +0000, Joseph S. Myers wrote:
> On Wed, 31 Oct 2012, Rich Felker wrote:
>
> > > * 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.
>
> I don't think you get the check that the token sequence is identical that
> way. And the check should not break multiple-include optimization.
I suppose it depends on the definition of "identically". I assumed it
just meant "equal as a truth value" but perhaps that's incorrect.
> > 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.
>
> The same rules are used for other optional ISO C extensions as well.
In that case, maybe GCC should just automatically treat __STDC_WANT_*
specially and issue an error if it's redefined between <> header
inclusions.
> > 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.
>
> The printf scanning for %n appears to be using parse_printf_format at
> present (outside C11 namespace), and I'd be dubious of having these
> functions scan in any way that isn't definitely identical to how the
> underlying C library will then parse the string.
I think it would be perfectly safe to parse it just according to the
standard and reject anything that's not valid according to the
standard as a constraint error. Even POSIX i18n formats could be
rejected.
Rich