Re: Implementation of C11 Bounds-checking interfaces

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 1 Nov 2012, Ulrich Bayer wrote:

> The #include_next way could be a bit problematic for headers that are
> included multiple times with different intentions. stdef.h  and the
> different __need_TYPE (e.g. __need_size_t) definitions are an example.
> We arrived at our current solution through trial and error and it seems
> to work but there might be problems on other systems.

For stddef.h it definitely makes sense to add the definition directly to 
GCC's header - and in general, the __need_* cases do rather cause problems 
for any system involving wrapper headers.  (For the most part, I'd like 
glibc's headers not to have such special __need_* handling.  If a glibc 
header handles some __need_* macro specially (so as not to define all the 
normal header contents), but that macro is only used by other glibc 
headers and not by any other cooperating project such as GCC, then the I 
think the contents controlled by the __need_* macro should move to a 
separate header to make glibc's headers more straightforward.  For 
example, instead of time.h considering __need_time_t, I think there should 
be a separate header such as bits/time_t.h whose only function is to 
define time_t, and headers currently defining __need_time_t and including 
<time.h> should include the new header instead.  See what I said in 
<http://sourceware.org/ml/libc-alpha/2012-08/msg00510.html>.)

> An remaining problem for scanf_s is that GCC does not understand the new
> scanf_s format string and cannot warn if the variable argument list does
> not correspond to the format string. Something a long the way of
> __attribute__((/format/(/scanf/s,m,n))) would be required.

Yes, that's another way in which modifications of GCC would make sense in 
support of this functionality.

> In the beginning, we thought the Annex K functions could be simply
> interpreted as wrappers that perform additional argument checks before
> calling the original C functions. However, this approach does not work
> for specific functions. For these functions, the only viable
> implementation in my opinion is a direct modification of the original C
> code.
> In more detail:

Thanks for the details.  I think they provide a reasonable case for, at 
least, including the functions in the context of the glibc project with 
appropriate modifications to existing glibc code to support the 
implementation of these functions - though maybe in a separate library so 
users need -l<something> (e.g. -lc_s, given the naming of the functions) 
to get them rather than getting them automatically from libc.so.

> 2) There are functions where the signature of the callback function has
> changed. These functions both add a void *context argument to the
> comparison function.
>  * bsearch_s
>  * qsort_s

glibc has qsort_r (rather obscure - added in 2.8 with no NEWS entry and no 
documentation in the glibc manual).  But of course using it externally to 
implement qsort_s would break namespace rules.

-- 
Joseph S. Myers
joseph@codesourcery.com