Public Comment Number PC-UK0152 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.8.2 Title: Error handling for complex functions Detailed description: Why does C9X specifically suggest that implementations need not bother with domain and range error handling for complex functions? This makes it quite impossible to use these functions in portable code if robustness is of any importance. The argument that they may need to be implemented inline doesn't hold water, as the same applies to the real functions. Note that domain errors CAN occur for the carg function and range errors for many of them. I suggest replacing paragraph 1 by: 1 The error handling for domain errors is as specified in section 7.7.1. 2 A overflowing range error occurs if the mathematical result of the function has either or both of its real and imaginary components that cannot be represented in an object of the specified type, without extraordinary roundoff error, because at least one is finite but too large. On an overflowing range error, it is implementation-defined whether the function returns an implementation-defined value for both components, or only those that cannot be represented; whether the integer expression errno acquires the value ERANGE is implementation-defined. 3 A underflowing range error occurs if the mathematical result of the function has real and imaginary components that cannot be represented in an object of the specified type, without extraordinary roundoff error, because at least one is finite but too small and the other is either finite but too small or zero. On an underflowing range error, the function returns a value of which both the real and imaginary components have magnitude no greater than the smallest positive real number in the specified type and are otherwise implementation-defined; whether the integer expression errno acquires the value ERANGE is implementation-defined. 3 An implementation may define other circumstances under which domain and range errors may occur. Recommended practice The error handling for complex functions should be as consistent with the real mathematical functions as possible, subject to the essential differences between the real and complex domains. In particular, the case where one component underflows or overflows but the other does not should be handled in a mathematically consistent fashion.