X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3F91B5CB.2C279231@phekda.freeserve.co.uk>
Date: Sat, 18 Oct 2003 22:51:07 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: nan, nanf, nanl, revision 2 [PATCH]
References: <200310181729 DOT h9IHThGL011985 AT speedy DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

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