Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ames!ucsd!usc!snorkelwacker!ai-lab!life!kingdon From: kingdon@pogo.ai.mit.edu (Jim Kingdon) Newsgroups: comp.std.c Subject: Re: Questions about NCEG Message-ID: Date: 4 Jun 90 02:17:16 GMT References: <13027@smoke.BRL.MIL> <13028@smoke.BRL.MIL> <1990May31.223436.23066@twinsun.com> <13039@smoke.BRL.MIL> Sender: news@wheaties.ai.mit.edu Organization: I see no organization here. Lines: 29 In-reply-to: gwyn@smoke.BRL.MIL's message of 3 Jun 90 20:11:14 GMT eggert@twinsun.com (Paul Eggert) writes: >While we're on the subject, NCEG should provide for a way for a program to >print a number so that it can be read back. ANSI C's "C" locale requires >that an IEEE 754 implementation's scanf() cannot read some numbers that >its printf() should be able to output, namely infinities and NaNs. gwyn@smoke.BRL.MIL (Doug Gwyn) writes: No, any use of NaNs and Infinities lies in the realm of undefined or implementation-defined behavior, and thus is not constrained by the C standard. Unless I'm misreading something, in the "C" locale, scanf ("%f", &x); where the input contains NaN has to return zero without reading any of the characters "NaN". Picking an alternate syntax like "0rnan" or something which is supposed to be more number-like doesn't help, as section 4.10.1.4 is very specific about what a number as input to strtod() (or scanf()) is supposed to look like. In another locale, the implementation is allowed to recognize other forms, so presumably NCEG wants to standardize a "NUMERIC" locale.