Eric Blake wrote: > Output wise, I've only seen a hex constant, but input wise, gcc's > __builtin_nan parses octal and decimal as well. Therefore, on systems > where long double is 128 bits (mantissa is 112 bits excluding the implied > 1 in normal numbers), a worst-case representation is 5 bytes for nan(), > plus 39 bytes for the octal representation with the 112th bit set, plus 1 > byte for a sign. So I think you need at least %046f before you can > guarantee that the 0 flag was handled correctly on a long double NaN.
OK, I'm changing the 20 bytes limit to 50 bytes. Bruno
