From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9335 invoked by alias); 20 Sep 2018 17:11:00 -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 9325 invoked by uid 89); 20 Sep 2018 17:10:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Thu, 20 Sep 2018 17:11:00 -0000 From: Joseph Myers To: Florian Weimer CC: Wilco Dijkstra , "libc-alpha@sourceware.org" , nd Subject: Re: [PATCH] Introduce --enable-math-noprivate In-Reply-To: <878t3wumw5.fsf@oldenburg.str.redhat.com> Message-ID: References: <878t3wumw5.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-09/txt/msg00377.txt.bz2 On Thu, 20 Sep 2018, Florian Weimer wrote: > > Similarly the strtod_nan* dependency seems worthwhile to remove too. > > I haven't thought about this. It's certainly a bit of a code > duplication. > > Joseph, any thoughts on that? Well, sharing the implementation of NaN parsing between the nan functions and the strto* functions seemed to make sense (the old approach of the nan functions calling strto* having had problems as discussed in bugs 16961 and 16962). And to share it at the binary level, not just the source level, meant GLIBC_PRIVATE exports. Since such exports are completely normal as the way for one glibc library to use internal functionality from another, I see no obvious reason to avoid using them by default, as opposed to with non-default configure options like this one. There's potential for the functions to get more complicated in the _Float128 / binary128 long double case - the present approach is unable to represent NaN significand bits outside the trailing 64 (and fixing that would mean having something like strtoull that handles integers up to at least 111 bits - in which case either that something would need exporting from libc as public, or it would need exporting as GLIBC_PRIVATE and duplicating with the new option). (You can construct NaNs with arbitrary payloads using setpayload functions, but having the nan/strto functions be able to do so as well would seem natural.) -- Joseph S. Myers joseph@codesourcery.com