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
