[3.13] pythongh-113841: fix possible undefined division by 0 in _Py_c…

…_pow() (pythonGH-127211) (pythonGH-127216)

Note, that transformed expression is not an equivalent for original one (1/exp(-x) != exp(x) in general for floating-point numbers). Though, the difference seems to be ~1ULP for good libm implementations.

It's more interesting why division was used from beginning. Closest algorithm I've found (no error checks, of course;)) - it's Algorithm 190 from ACM: https://dl.acm.org/doi/10.1145/366663.366679. It uses subtraction in the exponent.

(cherry picked from commit f7bb658)

(cherry picked from commit f41d8d8)

Co-authored-by: Miss Islington (bot) <[email protected]>
Co-authored-by: Sergey B Kirpichev <[email protected]>

Lib/test/test_complex.py

@@ -300,6 +300,11 @@ def test_pow(self):
                     except OverflowError:
                         pass
 
+        # gh-113841: possible undefined division by 0 in _Py_c_pow()
+        x, y = 9j, 33j**3
+        with self.assertRaises(OverflowError):
+            x**y
+
     def test_pow_with_small_integer_exponents(self):
         # Check that small integer exponents are handled identically
         # regardless of their type.

Misc/NEWS.d/next/Core_and_Builtins/2024-11-24-07-01-28.gh-issue-113841.WFg-Bu.rst

@@ -0,0 +1,2 @@
+Fix possible undefined behavior division by zero in :class:`complex`'s
+:c:func:`_Py_c_pow`.

Objects/complexobject.c

@@ -146,7 +146,7 @@ _Py_c_pow(Py_complex a, Py_complex b)
         at = atan2(a.imag, a.real);
         phase = at*b.real;
         if (b.imag != 0.0) {
-            len /= exp(at*b.imag);
+            len *= exp(-at*b.imag);
             phase += b.imag*log(vabs);
         }
         r.real = len*cos(phase);