This is the mail archive of the
mailing list for the glibc project.
Implementing C2X features in glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Thu, 29 Jun 2017 15:20:18 +0000
- Subject: Implementing C2X features in glibc
- Authentication-results: sourceware.org; auth=none
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
* 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
* 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