On Fri, 5 Nov 2021 14:25:35 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> * Add two new CLinker static methods to compute upcall/downcall method >> types >> * Clarify section on CLinker downcall type >> * Add section on CLinker safety guarantees > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java > line 134: > >> 132: * <p> >> 133: * Upcall stubs are generally safer to work with, as the linker runtime >> can validate the type of the target method >> 134: * handle against the provided function descriptor and report an error >> if any mismatch is detected. If the target method > > But, in the case of upcalls, errors can still occur if the native code casts > the pointer to the upcall stub to an incorrect type, e.g. > `FunctionDescriptor.ofVoid(ADDRESS, ADDRESS)`, but on the native side cast it > to `void (*)(void*)`, meaning the second argument would be garbage on the > Java side. i.e. there is still room for a mismatch the same as with downcalls. Yes and no. In a downcall, you just don't know what signature the downcall will feature in the native lib. So you pass a function descriptor and you hope it's ok. In the upcall case you _do_ know the signature of the Java upcall code you want to call, so you can validate the descriptor against that. Of course the native code can still cast things around in ways that blow things up, but the two problems seem somewhat different, at least to me. But I can tweak the text a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907
