RFR: 8343802: Prevent NULL usage backsliding [v6]

[Chen Liang]

On Mon, 10 Feb 2025 20:07:32 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Nizar Benalla 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 eight additional commits since the last revision:
>> 
>>  - pass an empty set the method rather than a boolean
>>    
>>    better exception handling/message when encountering a binary file
>>  - Merge remote-tracking branch 'upstream/master' into NULL-Checking-in-hotspot
>>  - filter out `.zip` files
>>  - Merge remote-tracking branch 'upstream/master' into NULL-Checking-in-hotspot
>>  - trivial change, if .java files are filtered out then so should .class files
>>  - revert to the original regex and remove the exclusion of os_windows.cpp
>>  - update based on feedback
>>  - Add a test to prevent NULL backsliding
>
> Regarding `globalDefinitions.hpp`, [8324686](https://bugs.openjdk.org/browse/JDK-8324686) is open. The description reads:
> 
>> One might think that redefinition might no longer be needed at all, since it's working around a pretty old issue. But apparently it's still the case that sizeof(NULL) != sizeof(void*) for 64bit builds. But a literal 0 (a 32bit int) is a valid null pointer constant.
> 
> This test is prevent more usages of NULL from backsliding, like what happened in [8349417](https://bugs.openjdk.org/browse/JDK-8349417). It would also check test, README and xml files.

@nizarbenalla I believe you misunderstood 8324686: it is that a global definition to support using NULL can be removed, but only after all NULL occurrences are replaced by nullptr. @iklam recommends to add a new global definition that makes future NULL usage fail fast (and can only happen after 8324686, as the macros are incompatible), which IMO is a better approach than directory scanning, and works better if there are extension code to hotspot that lives in directories that can't be discovered by this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/23466#issuecomment-2649131006