X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
From:	<ams AT ludd DOT luth DOT se>
Message-Id:	<200310181729.h9IHThGL011985@speedy.ludd.luth.se>
Subject:	Re: nan, nanf, nanl, revision 2 [PATCH]
In-Reply-To:	<3F916A07.7ABD24EB@phekda.freeserve.co.uk> "from Richard Dawe at
	Oct 18, 2003 05:27:51 pm"
To:	djgpp-workers AT delorie DOT com
Date:	Sat, 18 Oct 2003 19:29:43 +0200 (CEST)
X-Mailer:	ELM [version 2.4ME+ PL78 (25)]
MIME-Version:	1.0
X-MailScanner:	Found to be clean
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

According to Richard Dawe:
> > 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.

It does mention decimal and hexa-decimal numbers? Where? I can't see it.
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?

> 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.


Right,

						MartinS

- Raw text -