[3.13] gh-113841: fix possible undefined division by 0 in _Py_c_pow() (GH-127211) (#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)

Co-authored-by: Sergey B Kirpichev <[email protected]>

Author: miss-islington

Lib/test/test_complex.py

@@ -301,6 +301,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

@@ -147,7 +147,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);