> Several instances of function pointers in jdk.crypto.cryptoki are marked with 
> the dllimport attribute, which should only be applied to symbol declarations, 
> of which a typedef'd function pointer is not. This would only be useful if a 
> function pointer defined in the linked dll is desired to be imported, not if 
> the pointer itself is created locally and used to store a function address. 
> 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, even in other cases it would simply 
> be set to the address of a function anyway) assigning it to the pointer 
> before immediately dispatching when called, which bypasses this procedure 
> entirely and makes the attribute pointless.

Julian Waters has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains two additional 
commits since the last revision:

 - Merge branch 'master' into typedefs
 - Remove __declspec(dllimport) from pointers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9353/files
  - new: https://git.openjdk.org/jdk/pull/9353/files/f299e7c9..f6a94f41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=00-01

  Stats: 26587 lines in 1649 files changed: 13298 ins; 4444 del; 8845 mod
  Patch: https://git.openjdk.org/jdk/pull/9353.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9353/head:pull/9353

PR: https://git.openjdk.org/jdk/pull/9353

Reply via email to