X-Sybari-Trust: 0f73cef7 9ffcebbb 7a95d2f4 00000138 From: Martin Stromberg Message-Id: <200303180839.JAA03639@lws256.lu.erisoft.se> Subject: Re: strto{d,f,ld}, inf and nan patch To: djgpp-workers AT delorie DOT com Date: Tue, 18 Mar 2003 09:39:15 +0100 (MET) In-Reply-To: <6137-Tue18Mar2003092204+0200-eliz@elta.co.il> from "Eli Zaretskii" at Mar 18, 2003 09:22:05 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: > I think we should at least verify that is a hex number. Nope. Or at least probably not. Because the highest hex number we can read is an unsigned long long. That covers the mantissa of a long double. Where should the sign bit be indicated? Lately I've been thinking "nan(s,m,e)" while printing and with the ",e" part optional while scanning (it'll be ignored anyway). s == sign, m == mantissa, e == exponent. Or we could always omit "e". I just thought it nice to give the user the whole story. > Ideally, we should also generate the precise bit pattern as given by > . It cannot be too hard. Yes. All we need to agree on the format and if somebody else does the printing part, I'll do the strto{f,d,ld}() part. > Btw, what does C9x say about that specifies a bit pattern > which is not a NaN? I don't have the standard here but I'm pretty certain it must generate a NaN. That's why the "e" above will be ignored. And if "m" is 0, set it to some other documented non-zero value (otherwise we'd get Inf). Right, MartinS