RFR (S) 8225695: 32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)

[Alan Bateman]

On 13/06/2019 12:24, Aleksey Shipilev wrote:
> :
> Yes. My current problem is that jdk/jdk is broken pre-jdk13 fork. jdk-submit returned clean, and all
> other tests show the patch is okay. Current macros do what unsafe.cpp does in this situation. We can
> probably do the thing below, but it does not look much cleaner:
>
> diff -r 458d5b2269e9 src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h
> --- src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h  Thu Jun 13 11:37:38 2019 +0200
> +++ src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h  Thu Jun 13 13:22:29 2019 +0200
> @@ -59,4 +59,6 @@
>   #define _PKCS11WRAPPER_H 1
>
> +#include "jlong.h"
> +
>   /* disable asserts in product mode */
>   #ifndef DEBUG
> @@ -208,6 +210,6 @@
>   #define unsignedIntToCKULong(x) ((CK_ULONG) x)
>
> -#define jLongToCKMechanismPtr(x) ((CK_MECHANISM_PTR)(uintptr_t) x)
> -#define cKMechanismPtrToJLong(x) ((jlong)(uintptr_t) x)
> +#define jLongToCKMechanismPtr(x) ((CK_MECHANISM_PTR)jlong_to_ptr(x))
> +#define cKMechanismPtrToJLong(x) (ptr_to_jlong(x))
>
>   #ifdef P11_DEBUG
>
I think it looks a bit better as it avoids needing to stop and wonder if 
uintptr_t is correct or not.

I don't know who is still using 32-bit builds (maybe smaller run-times 
for micro services environments?) but a break breakage is not a P4/5 
issue so you shouldn't have any issue pushing this to jdk/jdk13 during RDP1.

-Alan