RFR: 8324680: Replace NULL with nullptr in JVMTI generated code

[David Holmes]

On Sun, 25 Feb 2024 10:53:20 GMT, Alan Bateman <alanb at 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