Mail Archives: djgpp-workers/2003/10/18/18:29:53
Hello.
ams AT ludd DOT luth DOT se wrote:
>
> According to Richard Dawe:
[snip]
> It does mention decimal and hexa-decimal numbers? Where? I can't see it.
Actually you are right. I thought paragraph 4 in section 7.20.1.3 was
referring to NAN(<stuff>), but it's talking about a normal number string given
to strto*.
> What it does say is it's "implementation-defined". There's not much
> point in talking about decimal or hexidecimal number after that, is
> there?
Since it's implementation-defined, we can do whatever we want with it.
Accepting numbers formatted in the usual way seems like a sensible thing to
do. Especially as it's easy to do.
I took a look at the glibc 2.2.93 sources and it uses strtoull with no base
specified to parse the n-char-sequence. It seems like a good idea to be
compatible with glibc.
> > 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?
>
> I think you're totally wrong. The sequence is implementation
> defined. Thus we could, if we wanted, use base 23 for it. Or some
> weird "nan(<sign>_<mantissa1>_<mantissa2>)" format (I did mention
> something like this while coding it but using commas, which I now see
> would be illegal).
>
> OTOH, if you really want it that way I won't stop you.
FWIW KB Williams has also written an implementation of nan* which he says
don't lose precision like ours do. (Our strto* functions lose precision on
NAN(<stuff>).) I haven't looked at his code yet.
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 -