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