This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Introduce --enable-math-noprivate
* 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
>> 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