The logic used in CMakeLists.txt#L149 can lead to the situation that on a 32-bit system where long long has size 8, the decision is made that SIXTY_FOUR_BIT should be defined and thus BN_BYTES becomes defined equal to 8 in header /include/openssl/bn.h. This situation occurs for example on Windows compiled with a 32-bit Visual Studio compiler.
This became recently evident to me in a seemingly invalid bug report of mine against the original openssl project (version 1.1.1t) openssl #20208, which has a new file /crypto/bn/rsa_sup_mul.c added, and an inappropriate preprocessor branch is entered in this case, namely rsa_sup_mul.c#L112 stopping with a linkage error due to the invalid attempt to use the 64-bit intrinsic _umul128 under 32-bit.
It seems to me that CMakeLists.txt#L149 should be corrected such that it only is entered on a system, where the pointer size is also equal to 8. One possible way of ensuring this could be by using the additional condition CMAKE_SIZEOF_VOID_P EQUAL 8.
janbar
commented
1 year ago
The logic used in CMakeLists.txt#L149 can lead to the situation that on a 32-bit system where long long has size 8, the decision is made that
SIXTY_FOUR_BITshould be defined and thusBN_BYTESbecomes defined equal to 8 in header /include/openssl/bn.h. This situation occurs for example on Windows compiled with a 32-bit Visual Studio compiler.This became recently evident to me in a seemingly invalid bug report of mine against the original openssl project (version 1.1.1t) openssl #20208, which has a new file /crypto/bn/rsa_sup_mul.c added, and an inappropriate preprocessor branch is entered in this case, namely rsa_sup_mul.c#L112 stopping with a linkage error due to the invalid attempt to use the 64-bit intrinsic
_umul128under 32-bit.It seems to me that CMakeLists.txt#L149 should be corrected such that it only is entered on a system, where the pointer size is also equal to 8. One possible way of ensuring this could be by using the additional condition
CMAKE_SIZEOF_VOID_P EQUAL 8.