Message412581
| Author |
vstinner |
| Recipients |
mark.dickinson, r.david.murray, rhettinger, tim.peters, vstinner |
| Date |
2022年02月05日.16:42:34 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1644079354.76.0.516488002368.issue46640@roundup.psfhosted.org> |
| In-reply-to |
| Content |
> The big blocker here is that a platform that fully supports C99 might not define the "NAN" macro. I don't think we can require that NAN be defined in order for Python to build (which is what the PR currently does, if I'm understanding it correctly).
If a platform doesn't implement NaN, it should define the Py_NO_NAN macro:
/* Py_NAN
* A value that evaluates to a NaN. On IEEE 754 platforms INF*0 or
* INF/INF works. Define Py_NO_NAN in pyconfig.h if your platform
* doesn't support NaNs.
*/
#if !defined(Py_NAN) && !defined(Py_NO_NAN)
// Use C99 "NAN" constant: quiet Not-A-Number (when supported)
# define Py_NAN NAN
#endif
Or do you mean that a platform can support NaN but don't define the <math.h> NAN macro? |
|