BUG: Fix order of Windows OS detection macros.#24762
Conversation
- The order should be `__MINGW32__/__MINGW64__`, then `_WIN64`,
and then `_WIN32`.
64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`.
32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`.
64 bit MSVC compilation defines `_WIN32` and `_WIN64`.
32 bit MSVC compilation defines `_WIN32`.
- Fixes numpy#24761.
- This is better than just relying on the order of evaluation in the whole
chain. Once Windows is detected (`_WIN32`), handle the possible known
Windows environments separately.
numpy/core/include/numpy/npy_os.h
Outdated
| #elif defined(__CYGWIN__) | ||
| #define NPY_OS_CYGWIN | ||
| /* We are on Windows.*/ | ||
| #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) |
There was a problem hiding this comment.
Perhaps it's time to retire WIN32 and WIN64.
As far as I can understand and according to QM Bites: Understand Windows OS Identification Preprocessor Macros:
_WIN32and_WIN64are defined by the compiler,WIN32andWIN64are defined by the user, to indicate whatever the user chooses them to indicate. They mean 32-bit and 64-bit Windows compilation by convention only.
MSVC has been defining _WIN32 and _WIN64 for a long time, provably at least since Visual Studio 2015, and in practice as early as in the days of 16-bit Windows:
There was a problem hiding this comment.
I agree. I kept them there because they were already there. @HaoZeke should we remove them?
There was a problem hiding this comment.
I agree. I kept them there because they were already there. @HaoZeke should we remove them?
Yup, that would be for the best I believe, please go ahead with that, also, thanks for the review and fix @mahge and @DimitriPapadopoulos
There was a problem hiding this comment.
Yup, that would be for the best I believe, please go ahead with that, also, thanks for the review and fix @mahge and @DimitriPapadopoulos
No problem at all. Fixed in 356325c.
- `WIN32`, `__WIN32__`, `WIN64`, `__WIN64__` are not standard macros defined
by Window compilers.
It should be enough to check for `_WIN32` and `_WIN64` alone.
|
Thanks @mahge . |
* BUG: Fix order of Windows OS detection macros.
- The order should be `__MINGW32__/__MINGW64__`, then `_WIN64`,
and then `_WIN32`.
64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`.
32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`.
64 bit MSVC compilation defines `_WIN32` and `_WIN64`.
32 bit MSVC compilation defines `_WIN32`.
- Fixes numpy#24761.
* Adjust the structure slightly and add comments.
- This is better than just relying on the order of evaluation in the whole
chain. Once Windows is detected (`_WIN32`), handle the possible known
Windows environments separately.
* Remove check for non-standard macros.
- `WIN32`, `__WIN32__`, `WIN64`, `__WIN64__` are not standard macros defined
by Window compilers.
It should be enough to check for `_WIN32` and `_WIN64` alone.
* BUG: Fix order of Windows OS detection macros.
- The order should be `__MINGW32__/__MINGW64__`, then `_WIN64`,
and then `_WIN32`.
64 bit MinGW compilers define `_MINGW32__`, `__MINGW64__`, `_WIN32`, and `_WIN64`.
32 bit MinGW compilers define `__MINGW32__`, and `_WIN32`.
64 bit MSVC compilation defines `_WIN32` and `_WIN64`.
32 bit MSVC compilation defines `_WIN32`.
- Fixes numpy#24761.
* Adjust the structure slightly and add comments.
- This is better than just relying on the order of evaluation in the whole
chain. Once Windows is detected (`_WIN32`), handle the possible known
Windows environments separately.
* Remove check for non-standard macros.
- `WIN32`, `__WIN32__`, `WIN64`, `__WIN64__` are not standard macros defined
by Window compilers.
It should be enough to check for `_WIN32` and `_WIN64` alone.
The order should be
__MINGW32__/__MINGW64__, then_WIN64, and then_WIN32._MINGW32__,__MINGW64__,_WIN32, and_WIN64.__MINGW32__, and_WIN32._WIN32and_WIN64._WIN32.Closes BUG: Order of OS detection macros (for Windows) seems faulty #24761. See the linked issue for more details.
This is a preliminary PR to accompany issue #24761. Please feel free to close it if there is a more appropriate way to handle it.