Submitter: Fred J. Tydeman (USA)
Submission Date: 2010-06-17
Subject: Remove error/no error choices in math
functions
Currently, several of the math library functions allow implementations too much choice as when to indicate errors. That is, one implementation may indicate an error, while another implementation may indicate no error for the same function call, e.g., atanh(1.0). This makes writing portable applications difficult.
There are two proposals here. They are independent of each other. They should each have their own vote. As written, these two proposals have no impact on current implementations. They are giving guidance and future directions.
On the other hand, if we decide to make these changes normative now, then change proposal 1 "should" to "shall" and remove the "Recommended Practice".
Proposal 1: add recommended practices.
7.12.4.4 The atan2 functions
Recommended Practice
atan2(zero,zero) should not be a domain error.
7.12.5.3 The atanh functions
Recommended Practice
atanh(+/-1.0) should be a pole error
7.12.6.5 The ilogb functions
Recommended Practice
ilogb(zero) should be a domain error. ilogb(infinity) should be a domain error. ilogb(NaN) should be domain error.
7.12.6.7 The log functions
Recommended Practice
log(zero) should be a pole error.
7.12.6.8 The log10 functions
Recommended Practice
log10(zero) should be a pole error.
7.12.6.9 The log1p functions
Recommended Practice
log1p(-1.0) should be a pole error.
7.12.6.10 The log2 functions
Recommended Practice
log2(zero) should be a pole error.
7.12.6.11 The logb functions
Recommended Practice
logb(zero) should be a pole error.
7.12.7.4 The pow functions
Recommended Practice
pow(zero,zero) should not be a domain error. pow(zero,less than zero) should be a pole error.
7.12.8.3 The lgamma functions
Recommended Practice
lgamma(zero) should be a pole error. lgamma(negative integer) should be a pole error.
7.12.8.4 The tgamma functions
Recommended Practice
tgamma(zero) should be a pole error. tgamma(negative integer) should be a domain error.
7.12.9.5 The lrint and llrint functions
Recommended Practice
lrint(too large) should be a domain error. llrint(too large) should be a domain error.
7.12.9.7 The lround and llround functions
Recommended Practice
lround(too large) should be a domain error. llround(too large) should be a domain error.
7.12.10.1 The fmod functions
Recommended Practice
If y is zero and x is not a NaN, fmod(x,y) should be a domain error.
7.12.10.2 The remainder functions
Recommended Practice
If y is zero and x is not a NaN, remainder(x,y) should be a domain error.
7.12.10.3 The remquo functions
Recommended Practice
If y is zero and x is not a NaN, remquo(x,y,quo) should be a domain error.
7.12.11.3 The nextafter functions
Recommended Practice
nextafter(+largest finite,+infinite) should be a range error. nextafter(-largest finite,-infinite) should be a range error.
7.12.11.4 The nexttoward functions
Recommended Practice
nexttoward(+largest finite,larger finite or infinite) should be a range error. nexttoward(-largest finite,-(larger finite or infinite)) should be a range error.
Proposal 2: add obsolescent features.
Add a new section to 7.29 Future library directions: 7.29.N Math <math.h:>
The following error conditions are obsolescent features.
Add the following to the Rationale for <math.h>:
For the same function call, having one implementation indicate an error and another implementation indicate no error makes it difficult to write portable application code. An example of this is: atanh(1.0); where one implementation calls it a pole error, while another implementation indicates no error. This ambiguity may be removed in a future revision of the standard.