[Cfp-interest 3237] Re: Can nan() set errno?

[Fred J. Tydeman]

On Sun, 18 Aug 2024 17:12:45 -0700 Jim Thomas wrote:
>
>
>
>> On Aug 18, 2024, at 3:19PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
>> 
>> On Thu, 15 Aug 2024 18:21:37 -0700 Jim Thomas wrote:
>>>> On Aug 14, 2024, at 3:28PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
>>>> 
>>>> On Wed, 14 Aug 2024 10:11:55 -0500 (COT) Fred J. Tydeman wrote:
>>>>> 
>>>>> Subject: [SC22WG14.26260] Can nan set errno?
>>>> 
>>>> 7.5 Errors <errno.h> has the general statement:
>>>> 
>>>> The value of errno may be set to nonzero by a library function call
>>>> whether or not there is an error, provided the use of errno is not
>>>> documented in the description of the function in this document.
>>>> 
>>>> 7.12.2 Treatment of error conditions has several specific statements
>>>> that apply to all <math.h> functions.  So, overrides the 7.5 general
>>>> statement. 
>>>> 
>>>> nan() is a <math.h> function, but is not a mathematical function.
>>>> strtod() is not a <math.h> function; but it has words about
>>>> overflow and underflow in the Returns section (that mirror 7.12.2).
>>>> 
>>>> So, what should happen for 
>>>> nan("a_very_long_string_________");
>>>> strtod("NAN(a_very_long_string_________)", nullptr);
>>>> when the n-char-sequence is longer than what the nan returned can hold?
>>> 
>>> As stated in the strtod Description (7.24.2.6 #5), "the meaning of the n-char sequence is implementation-defined." In particular, it does not need to be represented in the return NaN. An implementation is free to return the same NaN for all n-char sequences.
>> 
>> OK for the return value.
>> But, is an implementation allowed to indicate an error
>> (either via errno or the FP exception flags)?
>> 
>
>The strtod specification documents the use of errno (7.24.2.6 #12 and 13) which should mean that the functions can't set errno in other ways. One could quibble about whether "description" in 7.5 means in the general sense or refers to the Description section. For strtod, errno is documented in the Returns section.
>
>7.12.2 #1      says "Each function shall execute as if it were a single operation without raising SIGFPE and without generating any of the floating-point exceptions
>"invalid", "divide-by-zero", or "overflow" except to reflect the result of the function. This applies to the <math.h> nan() function which in the case above is equivalent to strtod(). One might argue that this doesn't fully cover strtod(). 
>
>F.8.7 says "Operations defined in 6.5.1 and functions and macros defined for the standard libraries change floating-point status flags and control modes just as indicated by their specifications (including conformance to ISO/IEC 60559). They do not change flags or modes (so as to be detectable by the user) in any other 
>cases." So Annex F implementations are not permitted to raise a floating-point exception for the strtod case you mention. 
>
>How far should we go to specify floating-point exceptions for implementations that don't conform to the Annex F (ISO/IEC 60559) specification for exceptions?

I am assuming this is for implementations that support NaNs.

Suppose, this long string to nan() were treated as a range error (overflow).
Then strtod() says nan() must return HUGE_VAL and ERANGE and/or "overflow"

Suppose, this long string to nan() were treated as a domain error.
Then strtod() says no conversion could be performed, and the
return value is0.0 and errno is not mentioned (so could be altered)

However, nan() requires that a NAN be returned, so neither of the above could be done.
Therefore, there is no error.  And by 7.12.2#7, error must be left alone.

7.12.2#7:
If a domain, pole, or range error occurs and the integer expression math_errhandling &
MATH_ERRNO is zero,268) then errno shall either be set to the value corresponding to the error or left
unmodified. If no such error occurs, errno shall be left unmodified regardless of the setting of
math_errhandling.



---
Fred J. Tydeman        Tydeman Consulting
tydeman at tybor.com      Testing, numerics, programming
+1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")
Sample C17+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.