bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib portability issues


From: Rich Felker
Subject: Re: gnulib portability issues
Date: Tue, 12 Jun 2012 11:53:52 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jun 12, 2012 at 09:07:05AM -0600, Eric Blake wrote:
> 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).

Signaling nans and trap representations are different things per the
standard. A signaling nan is a legitimate value that raises a floating
point exception flag (not a signal) when it's used in arithmetic, and
which is created in an implementation-defined way, if at all. A trap
representation (for any type, not just floating point) is a pattern of
bits that results in undefined behavior if it is read by an lvalue
expression that does not have character type.

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

I agree this is ugly. One possible solution would be a function (in
gnulib) to inspect a byte array and report whether it's a valid long
double representation.

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

I don't really care if the fix is an ugly bit test in in od.c or a
call to isnanl in od.c before the call to printf and letting gnulib's
isnanl handle the case; avoiding the printf replacement is enough for
me.

I do think only approaches that avoid reading the bits as LD80 before
they're known to be a non-trap representation can be 100% safe against
obscure machines, but on the other hand, avoiding machine-specific
code in od.c will probably make the situation better for practical
portability.

Rich



reply via email to

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