[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] checking "errno" for math operaton is safe to determine the error status?

Thanks for your explanation, Christian. Actually my question is not about thread safe or the original value 0 on errno. Probably I didn't express the point clearly. To be more clear, let me take expm1 as an example below.

On certain platform, expm1() is implemented as exp() minus 1. To calculate expm1(-1420.0), that will call exp(-1420.0) then substract 1. You know, exp(-1420.0) will underflow to zero and errno is set to ERANGE. As a consequence the errno keeps set there when expm1() returns the correct result -1. So for this situation, CPthon's api is_error() will raise overflow unexpectedly. Whose bug should it be scoped to? A bug of the platform? Isn't errno allowed to be set when calculation gets normal result? 


-----Original Message-----
From: Christian Heimes [mailto:christian at python.org] 
Sent: Thursday, April 11, 2019 8:24 PM
To: Xin, Peixing; python-dev at python.org; Mark Dickinson
Subject: Re: checking "errno" for math operaton is safe to determine the error status?

On 11/04/2019 11.45, Xin, Peixing wrote:
> Hi, Math experts:
> Looking at the codes below, for many math operations, CPython is checking errno to determine the error status even though the math function returns normal value back. Is it a safe solution? From the description here http://man7.org/linux/man-pages/man3/errno.3.html and https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152351, it looks apis probably set the errno when normal result is returned. Or being a side effect by calling other APIs in the implementation. In this situation, CPython's math operation might raise exceptions however in fact the result is correct.
> https://github.com/python/cpython/blob/master/Modules/mathmodule.c#L956
> https://github.com/python/cpython/blob/master/Modules/mathmodule.c#L864

This is safe because all places first set errno to 0. Errno is a thread
local variable, so other threads cannot influence the variable during
the calls.

This is one of the many quirks that Mark has implemented for platforms
bugs in various libm.