> to cinap's point, either nan -> float doesn't trap, and there is no protection > against bad fp math, or it does trap, and one has protection against producing > inadvertant nans.
> by the way, the same issue exists with sse. with SSE, i can assign SNaN's to variables and test for them with isNaN(). and only have the cpu trap when doing arithmetic on them, which i think is reasonable. but on 387, loading/storing the SNaN causes touble before i can even test for it. if NaN() produces a QNaN instead of a SNaN, then arithmetic will silently produce QNaN results, and we loose the protection for SSE. This is the behaviour when one clears FPINVAL from the FCR. for awk, i'm forced to one of these options with the current behaviour: - test the string before calling strtol() to make sure its proper decimal real number - clear FPINVAL in the FCR and loose the protection and test strtol() result with isNaN() both suck. if i'm going to have to parse the real number string myself to make sure its not nan, then what use is strtod()? and clearing FPINVAL just so i can test for isNaN() makes no sense. the program wasnt prepared to handle nan in the first place. maybe strtod() should not even parse "nan" when the FPINVAL bits are clear in the FCR an return 0.0 (similar to strtol) instead? So we interpret the FPINVAL bits in the FCR as "we dont want NaN's" and hence never produce them ourselfs? not sure whats worse... -- cinap
