Implementing C2X features in glibc

[Joseph Myers <joseph at codesourcery dot com>]

WG14 is working on C17, a bug-fix version of C11 with DR resolutions 
incorporated (and the standard sources converted from groff to LaTeX).  
glibc doesn't need to treat this any differently from C11 (any relevant DR 
resolutions should just be applied unconditionally).

After that there will be work on C2X, a major new revision of the C 
standard.  We need to consider what's appropriate regarding adding C2X 
library features to glibc before the release of the standard.

* C11 support was generally added only in 2.16, after the C11 standard was 
out.

* Various C99 features were added while the standard was in draft.  At 
least one block of features (new time functions) were added to and later 
removed from C9X drafts - and were accordingly added to and later removed 
from glibc (added Nov 1997, removed Jan 1999 - but that was entirely 
during development for glibc 2.1, so the interfaces didn't appear in any 
release).

* Some features may well be optional in which case we'll need to consider 
whether such a feature group is appropriate for glibc (as with the 
rejection of Annex K).  In some cases an external feature implementation 
may suffice (e.g. libdfp for decimal floating point support - various TS 
18661 parts are likely to be merged into C2X as optional features).

* I think we should generally consider features appropriate once they have 
been accepted into a C2X draft (subject to overall consideration of any 
optional feature block including thsoe features), but careful 
consideration needs to be given when adding such a feature about whether 
there are any problems with the specification, for which a fix might 
affect binary compatibility.  The default assumption is that once we've 
released with an interface, we need to keep compatibility with existing 
binaries using it, which might sometimes need compat symbols if the 
interface changes in later drafts.

* Some library features may depend on new compiler features.  If the 
implementation can only be built when new compiler features are available, 
that will delay addition to glibc, as features can only be added once we 
can rely on the compiler support (there might be longer-lived branches for 
such features, with the symbol versions keeping changing until we're ready 
to add such features).  For example, there is support in WG14 for adding a 
"short float" type (which wouldn't be required to be IEEE binary16, or to 
be narrower than float, but binary16 would be a natural choice in 
general).  As with _Float16 functions (which I've thought a bit about 
implementing, but have no immediate plans to work on), which short float 
functions would probably alias, building the library functions requires 
compiler support, so would depend on new compiler features and willingness 
to require such a new compiler to build glibc.

-- 
Joseph S. Myers
joseph@codesourcery.com