Public Comment Number PC-UK0143 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: Other (conflict with IEEE 754, LIA-1 and LIA-2) Committee Draft subsection: 7.7.1 Title: and floating-point signals Detailed description: This STILL forbids an implementation from trapping bad arguments to the mathematical functions, even if the user wants such a trap. I have had dozens of users horrified when I have told them that the C standard REQUIRES implementations to produce wrong answers without a trap, and sometimes without even an error flag. It is in obvious conflict with the stated intention of IEEE 754 and LIA-1, and actually prevents an implementation from conforming to both C9X and the proposed LIA-2 simultaneously. Despite this, H.3.1.2 Paragraph 1 claims that the C standard allows "hard to ignore" trapping and diagnostics as an alternative form of notification (as required by LIA-1), but it specifically FORBIDS this in many routines of the library (e.g. ). I suggest adding the following: 4 An implementation shall provide a mechanism for programs to be executed as described above. It may also provide a mechanism by which programs are executed in a mode in which some or all domain and range errors raise signals in an implementation-defined fashion. Recommended practice If domain errors raise a signal, the signal should be SIGILL. If range errors raise a signal, the signal should be SIGFPE. It should be possible for the program to run in a mode where domain errors and range errors that correspond to overflow raise signals, but range errors that correspond to underflow do not. Alternatively, people might prefer to use SIGFPE for both classes of error; there are arguments both ways, and either choice is reasonable. If this change is not made, H.3.1.2 should be corrected.