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
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
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
Precedence: bulk

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