Mail Archives: djgpp-workers/2003/10/18/12:29:22
Hello.
Martin Stromberg wrote:
>
> > * Make strto* support decimal numbers, when doing strto*("NAN(1234)", ...).
> > Currently it interprets everything inside NAN() as hexidecimal.
> > I think that is a bug, from reading the C99 specification.
>
> I don't have C99 here, but I think it said the string is
> implementation defined and the documentation clearly says (IIRC) it's
> interpreted as a hexadecimal number. Thus there is no bug.
In section 7.20.1.3 (page 703) it says:
"one of NAN or NAN(n-char-sequence opt ), ignoring case in the NAN part,
where:
n-char-sequence:
digit
nondigit
n-char-sequence digit
n-char-sequence nondigit"
It says a bit later (page 704):
"A character sequence NAN or NAN(n-char-sequence opt ), is interpreted as a
quiet NaN, if supported in the return type, else like a subject sequence part
that does not have the expected form; the meaning of the n-char sequences is
implementation-defined."
and refers to a footnote:
"An implementation may use the n-char sequence to determine extra information
to be represented in the NaN's significand."
The text talking about the meaning of the parameter to NAN talks about decimal
and hexidecimal numbers. So it seems to me that decimal and hexidecimal
numbers should be permitted.
I don't see any way of distinguishing between decimal and hexidecimal numbers,
unless we accept "0x" as an n-char-sequence at the start of the parameter to
NAN.
So I think we should take "0x" to mean that the number is hexidecimal,
otherwise assume it is decimal. As it stands the patch will accept octal
(01234) as a parameter to NAN. Perhaps the patch should be fixed to only
accept decimal & hexidecimal?
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
"You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek
- Raw text -