Other ISO C TR / TS / standard optional APIs

[Joseph Myers <joseph at codesourcery dot com>]

Having made proposals about the appropriateness of some ISO C APIs outside 
the main required standard set, I should also comment briefly on other 
optional ISO C APIs and APIs outside the main standard that are not 
currently supported by glibc.  The following are only tentative thoughts, 
*not* proposals that we agree on appropriateness or inappropriateness of 
certain APIs.

* C11 threads.  I believe we have consensus that these are appropriate 
(for libpthread).  The patches submitted in August need substantive review 
from a threads expert, as well as revisions for my review comments last 
month.

* C11 Annex K (bounds-checking interfaces).  I don't think there were 
particularly strong objections to supporting these, possibly in a separate 
libc_s.so, but no great liking for them either (and the discussion of a 
patch submission a while back died down without revised resubmission).

* TR 18037 (Embedded C).  Only ARM and MIPS support the fixed-point types 
in GCC.  I don't see the fixed-point functions as of much interest to 
glibc, and <iohw.h> is probably of even less relevance.

* ISO 24747 (Mathematical special functions).  In principle I'd consider 
these functions appropriate for glibc, probably libm rather than a 
separate library.  Many of them are particularly hard to implement if you 
want them accurate everywhere to within glibc's accuracy goals, and few of 
them have any / sufficient MPFR support.  So I expect they'd be a lot more 
work than TS 18661 functions (although TS 18661-4 functions also generally 
lack MPFR support, but it's easy to produce good-enough MPFR workarounds 
for those for use in test generation).

* Decimal floating point (TS 18661-2 and relevant functions in parts 3 and 
4).  I'd consider it appropriate for glibc (libc and libm) to contain at 
least enough to allow an external implementation to be conforming.  There 
are at least two pieces I think that would involve: libm fenv_t functions 
saving and restoring the decimal floating-point rounding mode in cases 
where that's handled in software rather than through hardware DFP support, 
with whichever library exporting a TLS variable with that software 
rounding mode; and scanf hooks analogous to printf hooks, with 
implementation-namespace versions of both sets of hook functions being 
exported, to allow DFP scanf to be implemented externally.  For other 
functions it may well make sense for them to be in a separate libdfp.so 
shared library.  I consider it an open question whether it would make 
sense in principle to include this code in the glibc sources and build it 
in a glibc build (for the few supported architectures), but there may not 
be any great advantage to doing so given the above pieces.  See 
<https://github.com/libdfp/libdfp> for the existing library.  It seems DFP 
is likely to be proposed as an optional feature for C2x, given 
longstanding implementation experience.

* TS 18661-5 (Supplementary attributes).  Current draft does not include 
any new library functions, but there are a few things that would need 
library support anyway (e.g. macros for float_t etc. that depend on the 
current state of the FENV_FLT_EVAL_METHOD pragma).  I think it's premature 
to consider the appropriateness of glibc support for such features.

* Reserved function names: cr* for correctly-rounding functions (TS 
18661-4).  I consider appropriateness of these an open question.

* Reserved function names: c* for complex versions of various real 
functions (C11 7.31.1, more in TS 18661-4; we already have clog10).  I 
consider appropriateness of these an open question (and in many cases 
there would be issues to determine the right Annex G-style handling of 
special cases, and the right branch cuts).  Cf. 
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1704.pdf> (from a time 
when new functions were not being considered for ISO C).  These functions 
do not generally have MPC support.

-- 
Joseph S. Myers
joseph@codesourcery.com