If a C runtime's math functions set errno to ERANGE, we assume it is a valid underflow if fabs(result) < 1.0.

However, because expm1 includes a -1.0, it underflows towards -1.0. This fails the above check, and so if a runtime's expm1() sets ERANGE we will raise a spurious OverflowError.

It's a bit cheap and nasty, but I think we could simply replace the line:

    if (fabs(x) < 1.0)

in is_error with

    if (fabs(x) < 2.0)

perhaps with an explanatory comment. All we need to do is distinguish underflow from overflow, and 2.0 is still clearly a _long_ way away from any overflow boundary.

It would be good to have a test that would trigger the behaviour, too.

I presume this is also worth an upstream report? Setting ERANGE on a result that's close to -1.0 is rather questionable.

I considered just switching to <2.0, but wasn't sure if I would be breaking some other unspoken behaviour there. But you're right, it's really just detecting underflow vs. overflow, so that's a much simpler way to check.

I've filed the upstream report. I suspect the errno is coming from the exp() call within the expm1() implementation, so it's underflowing towards 0.0 and then subtracting 1.

I've also got no idea how to write a test for this, given that it's a very thin wrapper around a platform's C runtime library. Our existing test discovered when the library changed behaviour to start setting errno, which is probably the best we can do.

> I've also got no idea how to write a test for this

Yep, that's fine. All I want is that at least one particular value that caused the spurious OverflowError is in the test suite somewhere, but it sounds as though that's already the case. I'd imagine that one of these two testcases should be enough to trigger it:

https://github.com/python/cpython/blob/44b0e76f2a80c9a78242b7542b8b1218d244af07/Lib/test/math_testcases.txt#L495-L496

Lines 500-504 are the ones that trigger it. Apparently there are no tests in that file for straight exp(), but the equivalent tests for those would return 0.0 and suppress ERANGE too.

> Lines 500-504 are the ones that trigger it.

Ah, right. Thanks.

> Apparently there are no tests in that file for straight exp()

Yes - that file was mostly written to give good coverage for places where we'd written our own implementations rather than simply wrapping an existing libm function, though I think we've now reverted to using the libm expm1 in all cases.

New changeset 3363e1cb05d0d19ed172ea63606d8cb6268747fc by Steve Dower in branch 'main':
bpo-46018: Ensure that math.expm1 does not raise on underflow (GH-29997)
https://github.com/python/cpython/commit/3363e1cb05d0d19ed172ea63606d8cb6268747fc

New changeset 5ae4265b8c8042c496e569b6dbf9ef107e1d5b31 by Miss Islington (bot) in branch '3.9':
bpo-46018: Ensure that math.expm1 does not raise on underflow (GH-29997)
https://github.com/python/cpython/commit/5ae4265b8c8042c496e569b6dbf9ef107e1d5b31

New changeset ca08655b808aed2e3abeb64cb67d98a79a661dda by Miss Islington (bot) in branch '3.10':
bpo-46018: Ensure that math.expm1 does not raise on underflow (GH-29997)
https://github.com/python/cpython/commit/ca08655b808aed2e3abeb64cb67d98a79a661dda