> Only 79 of the 128 bits of a long double are actually used
that one is notable
that one is notable
The long double type on x86 systems is the x87 80-bit floating point number. This type is non-IEEE 754 semantics; in particular, it makes the leading bit before the decimal explicit rather than implicit. The storage semantics are, well, weird. If you use XSAVE/FXSAVE to save x87 FPU state, then the floating point registers take up 16 bytes of space. If you use the FSAVE instruction, each register instead takes up 10 bytes of space. Similarly, the FLD/FSTP also use 10 bytes of space.
The i386 ABI states that long double is 108 bits with 32-bit alignment, while x86-64 uses 128 bits with 128-bit alignment. I suspect the reason for these sizes is to ensure that the size is a multiple of alignment, as well as guaranteeing the correct layout of saving the floating point stack to a long double stack[8]; array via (F)XSAVE in the x86-64 case.
So, is this a bug? Well, perhaps, but not in enquire.c. Experimental usage shows that only 10 bytes (79 bits) are actually used. This is clearly implemented as an x87 80-bit floating point number.
on an x86_64 GNU/Linux VM with GCC 8.1, set a double dbf to MAX_DOUBLE (1.7976931348623157e+308), set a long double dbld to (dbf + 1.0), and compare them (dbf == dbld); both values print the same, and the compare returns 1 (True).