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

[Jim Thomas]

> On Aug 21, 2024, at 7:25 PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> On Wed, 21 Aug 2024 17:42:17 -0700 Jim Thomas wrote:
>> 
>>> Suppose, this long string to nan() were treated as a range error (overflow).
>> 
>> Does some implementation do this? An implementation isn't permitted to add a range errors unless the floating result overflows or underflows.
> 
> glibc sets errno to ERANGE if there are lots of digits in the string.

I think this is clearly a bug. Range errors (in C23 and in all previous versions of C) are about numeric results being too large or too small in magnitude for the format. The nan() functions return NaNs, which are not numeric and have no magnitude.

Back to Richard Smith’s questions:

> From: Richard Smith <richardsmith at google.com <mailto:richardsmith at google.com>>
> To: ISO C <sc22wg14 at open-std.org <mailto:sc22wg14 at open-std.org>>
> Date: Fri, 2 Aug 2024 16:32:14 -0700
> Subject: [SC22WG14.26260] Can nan set errno?
> 
> Hi,
> 
> The documentation of errno is clear that it can be set to any non-zero
> value by a function whose specification doesn't mention errno. The
> specification of nan doesn't mention errno. Therefore one might conclude
> that nan can choose to set errno to any non-zero value.

> However, the specification of nan says that it's equivalent to a call to
> strtod, and the specification of strtod *does* mention errno, which
> presumably means that the strtod call that a call to nan is equivalent to
> must leave errno unchanged (the condition for setting errno to ERANGE is
> presumably not met since a NAN value should presumably not be considered to
> overflow even if the n-char-sequence doesn't fit in the payload).
> 
> So which interpretation wins? Is a call to nan really equivalent to a call
> to strtod, or is it allowed to affect errno? (There's a similar situation
> for atof, but it explicitly mentions errno in its specification to say that
> it may or may not have strtod's effect on errno, so the rule from 7.5/3
> that it may be set to any non-zero value doesn't apply.)
> 


I suggest the following response:

As specified, the nan() function really is equivalent to the corresponding use of strtod(). The nan() function is not allowed to affect errno. 

7.5 #3 says:

… 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.

strtod() documents use of errno for overflow and underflow, which prohibits other use of errno, including for the case that is equivalent to the nan() function. 

The specification of <math.h> functions includes the general specification in 7.12. Subclause 7.12.2 #2 says 

For all functions, a domain error occurs if and only if an input argument is outside the domain over which the mathematical function is defined. The description of each function lists any required domain errors; an implementation may define additional domain errors, provided that such errors are consistent with the mathematical definition of the function.

There are similar statements for range and pole errors. This specification would (in the absence of the equivalence to strtod) permit nan() to set errno but only in a way consistent with the meaning of the error. This qualification clearly excludes range errors (which pertain to numeric results being too large or small for the format) and pole errors. Since the meaning of the n-char-sequences is implementation-defined (see strtod 7.24.2.6 #5), one might be tempted to say some n-char-sequences are outside the domain of the function and define a domain error, but that is not an intended interpretation and the equivalence to strtod prohibits it.

- Jim Thomas

> 
> 
> 
> ---
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240829/95487c74/attachment.htm>