bug in xfont xlfd rounding code

[James Cloos]

I took a look at the various versions of ieee754.h in glibc.

The most significant difference is in long doubles.  (As an example, IBM
uses a pair of doubles, one for the most significant bits and one for
the least significant bits, but each is usable as is as a double.)

In total, there are 5 versions.  The primary, ones for 128-bit long
double and IBM's 128-bit long double, and ones for ia64 and sparc32.

The ia64 version differes only for long doubles.

The sparc32 version differs in the double section only in that it does
not support big endian __FLOAT_WORD_ORDER when __BYTE_ORDER is little
endian.  IOW, it looks like it was simply not updated when that
possibilty was first supported.

So, glibc supports three version of ieee754 doubles:

be:     1, 11, 20, 32
le:    32, 20, 11,  1
mixed: 20, 11,  1, 32

where mixed is le byte_order with be float_word_order.

I presume gcc would be the place to look to find which platforms have
__BYTE_ORDER == LITTLE_ENDIAN && __FLOAT_WORD_ORDER == BIG_ENDIAN.

Another interesting file is huge_val.h, which supports non-gcc compilers
by defining HUGE_VAL in terms of a union.  That suggests the the sh
platform is the only one supported by glibc which uses mixed above.

It looks like your patch should either separate out sh (as it now does
vax) or should take __FLOAT_WORD_ORDER into account.

The current version of glibc does not have any vax files in sysdeps,
and I remember almost none of the vax-specific info I once knew, so
I cannot comment on putative vax support.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6