bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib portability issues


From: Eric Blake
Subject: Re: gnulib portability issues
Date: Tue, 12 Jun 2012 09:07:05 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 06/12/2012 08:20 AM, Rich Felker wrote:

> To me, the only difference is the pain of replacing them. You cannot
> have these bit patterns in an LD80 without your program having invoked
> undefined behavior (accessing an object as a type other than its
> effective type or one of the allowed exceptions), so there's no
> fundamental reason either should handle it. In fact it's conceivable
> that machines could exist where even just loading the bit pattern into
> a floating point register would generate a signal,

But isnanl() is required to operate in spite of signaling
representations (that is, isnanl() need NOT load a bit pattern into a
floating point register).

> so really od should
> be performing the test on the unsigned char[] array *before*
> reinterpreting it to LD80 rather than calling a function that takes an
> LD80 argument to make the test..

But then you are forcing programs to add #ifdefs and sizeof(long
double)==12 checks, instead of letting libc do it for them.  That is,
testing for an invalid LD80 bit representation is
implementation-specific (it depends on the specific hardware and
compiler ABI before you even have a long double that can have the
invalid representation), but isnanl() is generic - we'd much rather have
the generic code do the implementation-specific filtering rather than
having to make every client learn the #ifdefs necessary for
implementation-specific bit pattern filtering.

That said, practicality may win on this one, and you may indeed convince
Jim that adding an #ifdef into coreutils' od.c is better than bloating
isnanl() for the majority of applications that never convert raw bit
patterns into long doubles.

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