Re: [PATCH] Introduce --enable-math-noprivate

[Florian Weimer <fweimer at redhat dot com>]

* Joseph Myers:

> 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.

Oohh, we have happy accident here that we can reuse the existing
historic __strtoul_internal export, which isn't GLIBC_PRIVATE for some
reason (probably for libstdc++'s sake).

> 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.)

Right, I think we might get more GLIBC_PRIVATE shortcuts in the future.
This is one reason why I think that --enable-math-noprivate might be
controversial: it's one more configuration to test, and we must make
sure that we can duplicate symbols (with hidden visiblity) into libm as
needed.

Thanks,
Florian