On Sun, 25 Feb 2024 10:53:20 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> This enhancement replaces uses of NULL with nullptr in the XML-description >> files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and >> `hotspot/share/prims/jvmti*.xls`. >> >> The following files are auto-generated from the `jvmti.xml` and `*.xsl >> files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, >> `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp` >> >> This addresses a category of NULL uses that wasn't dealt with by: >> [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837). >> >> Testing: >> - TBD: run mach5 tiers1-3 > > JVMTI agents can be developed in C or C++. If I read this changes correctly, > then this will replace all the NULLs in the generated spec with nullptr. I > wonder if this needs some setup in the Introduction section, e.g. the > Function Return Values subsection, to make this clear. As with the other NULL -> nullptr changes, when it involves text (as opposed to code) and we are discussing the general concept of nullness, then the word "null" should be used rather than the programmatic values `NULL` or `nullptr`. But if the source here is used to generated both the spec's functional descriptions and the code functions themselves, then we cannot make that distinction. I'm not sure this change was actually a good idea. At a minimum we need something like @AlanBateman suggests, something upfront to say that where the spec says `nullptr` it also means a C null pointer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1963338009
