Submitter: Fred J. Tydeman (USA)
Submission Date: 2010-06-17
Subject: Remove ambiguous choices in math functions
Currently, several of the math library functions allow implementations too much choice as how to indicate errors. That is, one implementation may indicate a domain error, while another implementation may indicate a range error for the same function call, e.g., lrint(DBL_MAX). This makes writing portable applications difficult in that there is no one specific error to check for in all cases.
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.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 a domain 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,less than zero) 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.
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>:
Having different implementations indicate different math errors for the same function call makes it difficult for applications to be portable code. An example of this is: pow(0.0,-1.0); where one implementation calls it a domain error, while another implementation calls it a pole error. This ambiguity may be removed in a future revision of the standard.