Document: WG14 N1500

Remove ambiguous choices in math functions


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.