No subject
Fred Tydeman
uunet!ibmsupt!ibmpa!tydeman
Wed Mar 20 15:17:00 PST 1991
Subject: Request For Interpretations: Answers from ANSI C committee.
The ANSI "C" committee processed my five formal Request For
Interpretations at the March 6-8, 1991 meeting. A summary of the
questions and answers follows.
1) What is the result of: printf( "%#.4o", 345 );? Is it "0531" or is
it "00531"?
Answer: "0531". The precision is increased only if necessary.
2) What is the result of: strtod( "100ergs", &ptr);? Is it 100.0 or is
it 0.0?
Answer: "100.0". strtod and fscanf are different -- fscanf expects a
sequence that matches what works for strtod. fscanf can easily get into
corners that it can't back out of, as it is constrained not to "leave
unread" more than one byte. On the other hand, strtod must do a
reasonable job with any input string.
Thus, fscanf(fp,"%f", &f) when handed "100ergs" on its input stream will
fail to convert, lose "100e", and leave "rgs" unread. (4.9.6.2) In
contrast, strtod("100ergs", &ptr) returns 100.0 and sets the pointer to
the 'e' character. (4.10.1.4)
3) Assuming that 99999 is larger than DBL_MAX_10_EXP, what is the result
of: strtod( "0.0e99999", &ptr);? Is it 0.0, HUGE_VAL, or undefined?
Answer: 0.0. The result of strtod("0.0e99999", &ptr); is exactly
representable, i.e., lies within the range of representable values.
Therefore, by 4.10.1.4 "Returns", the value zero shall be returned in
this case, and errno shall not be set. (This means that implementations
have to test for the special case of zero when creating floating-point
representations from characters).
Note also that strtod("0.0e-99999", &ptr); is not a case of underflow,
so errno shall not be set to ERANGE in this case.
4) The original questions were poorly formed. As it turns out, there
is no way to find out what locale a program is in! Therefore, new
questions were formed and answered based upon the intent of originals.
Page 108, lines 14-16 describes what is affected by each locale portion.
Is it the LC_NUMERIC locale category which affects the
implementation-defined behavior of strtod etc? Answer: Yes.
How can one guarantee that strtod functions are in the "C" locale?
Answer: execute setlocale(LC_NUMERIC, "C") or execute setlocale(LC_ALL,
"C").
What is meant by "other than the C locale (for strtod)"? I.e., how can
one ensure that strtod is not in the "C" locale? Answer: successfully
execute setlocale(LC_NUMERIC, str) or setlocale(LC_ALL, str) to some
implementation-defined string str which specifies a locale different
from the "C" locale. No universally portable method can be provided,
because the functionality is implementation-defined.
5) What is meant by 'representable floating-point value'?
Answer:
Principles for C Floating-point representation.
1. "Value" refers to the abstract (mathematical) meaning;
"representation" refers to the implementation data pattern.
2. Some (not all) values have exact representations.
3. There may be multiple exact representations for the same value; all
such representations shall compare equal.
4. Exact representations of different values shall compare unequal.
5. There shall be at least one exact representation for the value zero.
6. Implementations are allowed considerable latitude in the way they
represent floating-point quantities; in particular, as noted in Footnote
10 on page 15, the implementation need not exactly conform to the model
given in 2.2.4.2.2 for "normalized floating-point numbers".
7. There may be minimum and/or maximum exactly-representable values;
all values between and including such extrema are considered to "lie
within the range of representable values".
8. Implementations may elect to represent "infinite" values, in which
case all real numbers would lie within the range of representable
values.
9. For a given value, the "nearest representable value" is that
exactly-representable value within the range of representable values that
is closest (mathematically, using the usual Euclidean norm) to the given
value.
(Points 3 and 4 are meant to apply to representations of the same
floating type, not for a comparison between different types.)
This implies that a conforming implementation is allowed to accept a
floating-point constant of any arbitarily large or small value.
Fred Tydeman, IBM, Palo Alto, Calif. (415) 855-4430
Internet: tydemanaibmpa.awdpa.ibm.com uucp: uunet!ibmsupt!tydeman
More information about the Numeric-interest
mailing list