-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, as stated in the official documentation:
"A program that uses public symbols defined by a DLL is said to import them. When you create header files for applications that use your DLLs to build with, use __declspec(dllimport) on the declarations of the public symbols. The keyword __declspec(dllimport) works whether you export with .def files or with the __declspec(dllexport) keyword."
In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress) and assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and making the attribute pointless.
"A program that uses public symbols defined by a DLL is said to import them. When you create header files for applications that use your DLLs to build with, use __declspec(dllimport) on the declarations of the public symbols. The keyword __declspec(dllimport) works whether you export with .def files or with the __declspec(dllexport) keyword."
In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress) and assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and making the attribute pointless.
- relates to
-
JDK-8288293 Windows/gcc Port
-
- Draft
-