[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFT: *printf-posix modules

From: Eric Blake
Subject: Re: RFT: *printf-posix modules
Date: Wed, 23 May 2007 18:53:47 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070221 Thunderbird/ Mnenhy/

Hash: SHA1

According to Bruno Haible on 5/23/2007 4:10 PM:
>>>       ASSERT (strlen (result) == 20 + 3
>>> !       && strisnan (result, strspn (result, " "), strlen (result) - 3, 0)
>>>         && strcmp (result + strlen (result) - 3, " 33") == 0);
>> This assertion will fail if the implementation produces an n-char-sequence 
>> NaN.
> It will fail if the implementation produces an n-char-sequence which is
> longer than 15 bytes. Do you find this is likely? If so, feel free to bump
> the number 20 to 50 or so.

The only rendition of n-char-sequences that I am familiar with is
basically a C-literal integer between the () specifying how the bits
within the mantissa portion of the floating point NaN are to be set.
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.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]