On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner <vstinner@python.org> wrote:
I made a change to require C99 <math.h> "NAN" constant [...]
There's a separate discussion topic lurking here. It's equally in need of discussion here (IMO), but it's orthogonal to the "should we require C99" discussion. I've changed the subject line accordingly to try to avoid derailing that discussion. Unlike the other things Victor mentions ("copysign", "round", etc.), the NAN macro is not required to be present by C99. Instead, the standard says that "NAN is defined if and only if the implementation supports quiet NaNs for the float type" (C99 §7.12p5). Victor is proposing in GH-31160 <https://github.com/python/cpython/pull/31160> to require the presence of the NAN macro in order for CPython to build, which under C99 is equivalent to requiring that the C float type supports quiet NaNs. That's not the same as requiring IEEE 754 floating-point, but it's not far off - there aren't many non-IEEE 754 floating-point formats that support NaNs. (Historically, there are essentially none, but it seems quite likely that there will be at least some non-IEEE 754 formats in the future that support NaNs; Google's bfloat16 format is one example.) So there (at least) three questions here: - Should we require the presence of NaNs in order for CPython to build? - Should we require IEEE 754 floating-point for CPython-the-implementation? - Should we require IEEE 754 floating-point for Python-the-language? For the first two, I'd much prefer either to not require NaNs, or to go the whole way and require IEEE 754 for CPython. Requiring NaNs but not IEEE 754 feels like an awkward halfway house: in practice, it would be just as restrictive as requiring IEEE 754, but without the benefits of making that requirement explicit (e.g., being able to get rid of non-IEEE 754 paths in existing code, and being able to tell users that they can reasonably expect IEEE 754-conformant behaviour). Note that on the current main branch there's a Py_NO_NAN macro that builders can define to indicate that NaNs aren't supported, but the Python build is currently broken if Py_NO_NAN is defined (see https://bugs.python.org/issue46656). If the answer to the first question is "No", then we need to fix the build under Py_NO_NAN. That's not a big deal - perhaps a couple of hours of work. -- Mark