This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: QNaN and SNaN definitions


On Tue, Mar 19, 2002 at 10:34:11PM +0100, Hartvig Ekner wrote:
> I have found the glibc definitions for QNaN and SNaN are wrong for MIPS
> (and some other architectures).
> 
> Unfortunately, IEEE let it up to the implementations to decide how
> the bit distinguishing between QNaN and SNaN was to be encoded, and
> most of the world choose that particular bit==1 to mean QNaN. 
> 
> For MIPS, HPPA and maybe others, that bit is reversed, and has to be ==0
> to mean QNaN.
> 
> As far as I can see, all cases inside glibc don't care whether things
> are a QNaN or SNaN (eg. isnan(), fpclassify etc) and therefore work
> correctly for both cases, but some of the public header files in glibc
> which end up in /usr/include are wrong:
> 
> sysdeps/ieee754/bits/nan.h
> 
> 	Specifically specifies a NaN (QNaN) to 7fc0.0000.
> 
> sysdeps/ieee754/ieee754.h:
> 
> 	Defines 8 structures like:
> 
>     /* This format makes it easier to see if a NaN is a signalling NaN.  */
>     struct
>       {
> #if     __BYTE_ORDER == __BIG_ENDIAN
>         unsigned int negative:1;
>         unsigned int exponent:8;
>         unsigned int quiet_nan:1;
>         unsigned int mantissa:22;
> 
> I can send in patches to fix this for MIPS, but I would think this is
> inappropriate and that some of you glibc people would have to decide how
> to deal with this. If you can tell me how you want it fixed, I will be
> happy to deliver the patches, but I need a machine specific #define to
> look at in these header files. I would like to avoid separate MIPS versions
> of these header files if possible (maintenance issues).

Just create a new sysdeps/mips/bits/nan.h with the right bits.

> 
> In nan.h, it is clear what has to be done. 
> 
> In ieee754.h it is less clear. One can leave things as they are, but then
> peoples apps will not work without them knowing the difference. Maybe define
> machine-dep constants to be used with the quiet_nan field, or more 
> drastically, rename the quiet_nan field to signalling_nan. Is this an
> option at all?
> 

You can create a new sysdeps/mips/ieee754.h and change quiet_nan to
signalling_nan. Any codes depending on quiet_nan will fail on mips


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]