bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isnanl, printf, and non-IEEE values


From: Eric Blake
Subject: Re: isnanl, printf, and non-IEEE values
Date: Tue, 19 Jun 2012 07:07:10 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

On 06/19/2012 06:51 AM, John Spencer wrote:
> *sigh*.
> talking to you guys is like talking to a wall.

Please don't swear.  This is a publicly archived list, and you are
coming across rather offensive.  A positive attitude is more likely to
foster cooperation than berating others.

>> There's no force here.  The process is entirely voluntary.
>>
> ah perfect then, so please educate me where i can find the hidden switch
> to tell GNULIB:
> 
> "NO I DONT WANT YOUR F****** BROKEN REPLACEMENT FUNCTIONS, THAT EVEN
> FAIL TO COMPILE WITH AN #ERROR, BECAUSE ITS AUTHORS ARE MORONS THAT
> DISABLED THE EXISTING PORTABLE FALLBACK CODE" ?

This is your complaint about 'closein', and I think we are making
progress here.

The problem is that the existing fallback code is not perfect - if you
would help us come up with a portable replacement that works
_efficiently_, then we could remove the #error everywhere.  In the
meantime, the #error continues to serve its purpose - it has let us
improve both DragonFly and musl (thanks to recent commits adding
stdioext functions) and gnulib (to use those functions instead of poking
at musl FILE* internals or falling back to the #error), and the end
result will be that programs released against the latest version of
gnulib should now compile without error on musl, with no further effort
on your part, and without the speed penalty of the fallback code.

> 
> or
> 
> "YES, I AM FINE WITH A PRINTF THAT BAILS OUT ON INVALID BIT PATTERNS,
> BECAUSE THAT'S UB AND HOW C WORKS.

What's wrong if gnulib decides to throw another layer on top of your
libc?  Yes, the binaries compiled that way will be larger than they
could have been, but that's the choice of the program author to use its
own format routines instead of deferring to libc.

But if you absolutely want to guarantee that programs compiled against
musl will pick up the musl printf instead of the gnulib replacement,
then install a config.site that primes the autoconf cache to override
the decisions and claim that printf matches the features gnulib was
looking for even without running the configure tests.  For example,
priming gl_cv_func_printf_infinite_long_double=yes in your config.site
file would skip gnulib's m4 test of LD80 behavior, and as long as you
then ignore the testsuite failures, the rest of your program will
happily use the UB of passing an out-of-range LD80 number to musl's
printf instead of gnulib's replacement.

> you know, reading 20.000 lines of ugly generated autoconf script code is
> pretty though; i can't spot the "voluntary" option myself.

No need to go through that many lines; instead, look at the gl_cv_*
cache values in config.cache for the shorter list of the variables that
you might want to prime, or read the source code (the .m4 files) instead
of the generated output code (the configure file).

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]