issue 7006 - std.math.pow (integral, integral) crashes on negative exponents

Timon Gehr timon.gehr at
Wed Dec 18 02:14:34 UTC 2019

On 18.12.19 01:37, Timon Gehr wrote:
> On Wednesday, 18 December 2019 at 00:03:14 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 17 December 2019 at 23:29:53 UTC, Timon Gehr wrote:
>>> ...
>>> on x86. For instance, if I added a single special case for 
>>> std::pow(0.0,0.0) to a standards-compliant C++17 implementation for 
>>> x86-64 with floating-point support, which values could I return 
>>> without breaking C++17 standard compliance?)
>> Whatever you like.  It is implementation defined.  That does not mean 
>> it is encouraged to return something random.
>> ...
> "If a domain error occurs, an implementation-defined value is returned 
> (NaN where supported)"
> I.e., what you are saying is that even if the implementation supports 
> NaN, it may return non-NaN, the above statement notwithstanding?

Perhaps what you mean to say is that the C++ standard is understood to 
be so lax that it doesn't actually define the expected result of pow for 
anything but the listed special cases, such that pedantically speaking, 
pow could return NaN (or, usually, any other value) for all other pairs 
of arguments (usually, without raising a domain error)?

The webpage says that the function raises the first argument to the 
power of the second. For floating point, this usually means it returns 
the correct result rounded according to the current rounding mode. 
However, if it is indeed true that in the context of the C++ standard, 
this instead means absolutely nothing, this would successfully refute my 
claim that the webpage (means to) state(s) _precisely_ that pow(0.0,0.0) 
may return 1 or NaN after you claimed that the webpage does not say that 
1 or NaN are both allowed values. It can't be true that the standard 
does not allow one of those two values, as NaN is explicitly allowed and 
actual implementations return 1.

In this case, pow(0.0,0.0) being unspecified would be exactly as 
significant as pow(2.0,2.0) being unspecified, and it would have exactly 
as much bearing on the topic of this thread. The Wikipedia article could 
then perhaps also be updated to explain that pow being unspecified is 
something that holds for most arguments, including (0.0,0.0).

More information about the Digitalmars-d mailing list