From: Joseph Myers <joseph@codesourcery.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: <libc-alpha@sourceware.org>
Subject: Re: Add feature test macro _ISOC2X_SOURCE
Date: Fri, 09 Aug 2019 13:00:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.21.1908091234100.20081@digraph.polyomino.org.uk> (raw)
In-Reply-To: <87k1bm6c99.fsf@oldenburg2.str.redhat.com>
On Fri, 9 Aug 2019, Florian Weimer wrote:
> * Joseph Myers:
>
> > This patch does not itself enable anything new in the headers for C2X;
> > that is to be done in followup patches. (For example, most of the TS
> > 18661-1 functions should be declared for C2X without any
> > __STDC_WANT_IEC_60559_BFP_EXT__ being needed, but the ones that
> > 18661-1 adds to Annex F because of their close relation to IEEE 754
> > formats do still need the WANT macro in C2X.)
>
> What happened to the plan to rename the TS 18661-1 functions? Has a
> formal decision been made?
There isn't a plan; there's someone who wants to rename either some or all
functions, while the CFP group is against ("3) Renaming functions:
Against, since already implemented as is, names fit with pre-part 1 C,
consistent with existing C standard, names fit function" - see pages 28-29
of <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2376.pdf>), and no
specific decision ("This risk has not yet been evaluated. Several ideas
have been discussed to resolve these issue, but none has yet resulted in a
proposal that would find consensus." in the editors' report).
I don't think that's actually relevant to the feature test macro anyway;
it's explicitly stated that the API enabled by the feature test macro
might be unstable before C2X is released. (While the ABI would be subject
to the usual compatibility rules in the event of API changes that could
break ABI compatibility; for example, we should keep compat symbols when
changing totalorder to have pointer arguments; because that's considered a
defect fix to 18661-1, there would in any case be no need to keep the old
totalorder version available as an API as opposed to as an ABI.)
Even without renaming it's plausible some 18661-1 functions will not end
up in C2X; specifically, the changes to minimum / maximum operations in
IEEE 754-2019 could result in fmaxmag / fminmag being removed (see
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2273.pdf>). I expect to
have different __GLIBC_USE names for different subsets of 18661-1 (the
subset in C2X unconditionally; the subset that's only in C2X when
__STDC_WANT_IEC_60559_BFP_EXT__ is defined; any subset that's not in C2X
at all so should not be declared for __STDC_WANT_IEC_60559_BFP_EXT__ in
strict C2X conformance mode, unless we end up completely obsoleting such
names as APIs). Depending on the precise form 18661-3 integration takes
there may also be a question about the exact feature test macros for
18661-3 functions corresponding to the functions that, in C2X, need
__STDC_WANT_IEC_60559_BFP_EXT__ for float / double / long double (a subset
of the ones currently using "__GLIBC_USE (IEC_60559_BFP_EXT) ||
__MATH_DECLARING_FLOATN").
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2019-08-09 13:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-09 0:03 Joseph Myers
2019-08-09 7:15 ` Florian Weimer
2019-08-09 13:00 ` Joseph Myers [this message]
2019-08-09 15:39 ` Florian Weimer
2019-08-09 17:06 ` Joseph Myers
2019-08-13 7:21 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1908091234100.20081@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).