From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89128 invoked by alias); 9 Aug 2019 13:00:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 88932 invoked by uid 89); 9 Aug 2019 13:00:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=jtc1, Against, H*f:sk:87k1bm6, UD:www.open-std.org X-HELO: esa4.mentor.iphmx.com IronPort-SDR: 2B/cH5ribC4CwS6f40jEHs7RuCGArCTozHk2DJ4QASFt413Xoat/iXspJ3Z77rXRafng97ENPk Upm7uyFd1zqjzy6J4KfOn+3MmTxUVbMKpC/VQXooZFygkRnxRH3ggHuHLwHABebiPoXDdyP6le nsD9okqNvHe0+nvClR4xKwNEsxGX4F/swL6/wNkE9U987uaLWD0qLD/azVedx3rR5hTL5ztxux jcZkY4b9G/QguAEAaTqtn4wFgWMH1zfa34kPY7l9R776kqHyDgvt7Z2W7XWvPChKIW27dCFRSg bcQ= IronPort-SDR: JEgU2T7IK4DSpWmxKA8VVrCNHrGVTS6AzF+GvZNCldlLjVOetX0PVs2irD8yTWemZtWcHEbwZg 2U9whwYm4ohx3dlp4vr/ilDeqYWMU3QVtqtolhCAAp/MF8SUkyfJPOcZEBu2mMsuesNfZ8yO98 9/SYtWk59nXuqdMBVYueO8jAy7pWnKame7Ix/LCCQrDEC72GEp4S1UjFdw3p7E3OqG5gbYV+Va uDUsjL3G/fD809pzBCxxfX3LEAtAoHhckqL1vHI22j+AGr7hdaOqPRLqafm6vcQjig9StHyV7I sBY= Date: Fri, 09 Aug 2019 13:00:00 -0000 From: Joseph Myers To: Florian Weimer CC: Subject: Re: Add feature test macro _ISOC2X_SOURCE In-Reply-To: <87k1bm6c99.fsf@oldenburg2.str.redhat.com> Message-ID: References: <87k1bm6c99.fsf@oldenburg2.str.redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-08/txt/msg00167.txt.bz2 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 ), 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 ). 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