X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Martin Stromberg Message-Id: <200304220902.LAA06094@lws256.lu.erisoft.se> Subject: Re: Yet another try on nan in strto{f,d,ld} To: djgpp-workers AT delorie DOT com Date: Tue, 22 Apr 2003 11:02:14 +0200 (MET DST) In-Reply-To: <1225-Tue22Apr2003111232+0300-eliz@elta.co.il> from "Eli Zaretskii" at Apr 22, 2003 11:12:33 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Eli said: > > From: > > Date: Sun, 20 Apr 2003 20:04:40 +0200 (CEST) > A minor nit: you say twice that the ``-'' causes the sign bit of a NaN > to be set. I do? Please post quote both. (I can't find what you mean.) > Also, I'm a bit worried by the typecast juggling you do: won't that > get in our way when/if we want to add ``restrict'' qualifiers to the > library sources and headers? Do you mean "unconst" or "return *(double *)(&n)"? Or something else? For unconst, I have no idea. I've just duplicated earlier present unconsts. For return ..., I don't think restrict have anything to do with return. > Finally, instead of saying > > the return value is a NaN with the mantissa bits set to > @code{@var{hex-number}&0xfffffffffffff} > > isn't it better to say > > the return value is a NaN with the mantissa bits set to > the lower 52 bits of @var{hex-number} > > ? I think the latter is more clear, especially if the reader is not > too familiar with bitwise ops and hex numbers. Yes, much better. Thanks! The plan is commit strtof() and strtod() soon. We need to decide if the integer bit influences the NaNess of a long double for strtold(). Or should I just commit that one too after deciding that that bit must be set? (It's what *printf() do. A NaN with that bit cleared is showed as Unnormal.) Right, MartinS