Re: Implement C11 annex K?

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

On Sun, 10 Aug 2014, Adhemerval Zanella wrote:

> Last iteration to add C11 annex K in GLIBC was from Ulrich Bayer [1] and it
> got stalled not because GLIBC maintainers decided this is not worth of adding,
> but because the proposer didn't send any more updates based on comments.
> 
> So you can take this initial approach as base for your work or if you are willing
> start a new thread/implementation. However, keep in mind that since GLIBC is
> community driven project, it will probably require a lot of iterations of
> submission and revisions.

Indeed - and when different people in the community suggest different 
things about how to handle some issue, it's your job as submitter to drive 
things to consensus.  Also: I advise getting the copyright assignment in 
before sending any large patches; people may not want to look at large 
unassigned patches.  (Ulrich Bayer and SBA Research GmbH did get their 
assignments done, though I think it was a while after patches were first 
posted.)

I believe the basic approach was agreed in the previous threads (of which 
there were I think several spread over an extended period of time).

* The new functions would go in a separate library libc_s unless so 
closely tied to existing libc functions that this is problematic.  If it's 
natural to implement them in terms of functions not currently exported 
from libc, or exported from libc only with names not in the C11 reserved 
namespace, then additional reserved-namespace exports can be added to libc 
at the GLIBC_PRIVATE symbol version.

* Declarations in headers would be conditional on __STDC_WANT_LIB_EXT1__ 
(directly, not on an __USE_* macro, because what matters is the definition 
of __STDC_WANT_LIB_EXT1__ when affected headers are included, not when 
some unaffected C11 header is included, which is incompatible with the 
__USE_* approach).  Checks for consistency of __STDC_WANT_LIB_EXT1__ when 
different headers are included might be omitted given the WG14 mood for 
simpler __STDC_WANT_* macro semantics.

* The <stddef.h> and <stdint.h> changes should be implemented in GCC (with 
the appropriate conditionals in the headers), with glibc's <stdint.h> 
needing changing as well.

* Pay attention to various C11 DRs relating to Annex K.

* All normal conventions for patches adding new interfaces apply, 
including giving the new interfaces the symbol version (e.g. GLIBC_2.21) 
of the first glibc version with the interface and ensuring sufficient 
testsuite coverage.

* Some functions will need versions for _FILE_OFFSET_BITS=64 / 
_LARGEFILE64_SOURCE (e.g. tmpfile, fopen, freopen have such versions, so 
the _s variants of those functions should also have such versions).  In 
general, you'll need to understand what variants there are of any existing 
function getting an _s variant, so as to work out which of those variants 
need replicating for *_s.  (Another example is the variants of printf / 
scanf functions in libnldbl.a for -mlong-double-64 on some architectures.)

-- 
Joseph S. Myers
joseph@codesourcery.com