RFR: 8240110: Improve NULL

[Leo Korinth]

On 20/04/2020 11:23, Kim Barrett wrote:
>> On Apr 19, 2020, at 10:35 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 20/04/2020 10:58 am, Kim Barrett wrote:
>>>> On Apr 19, 2020, at 6:13 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> On 20/04/2020 3:08 am, Leo Korinth wrote:
>>>>> What about this?
>>>>> #define JVMCI_CHECK_0             JVMCI_CHECK_(NULL_WORD)
>>>>
>>>> Why does this integer returning macro need to return NULL_WORD? As I said above if writing this directly I would write "return 0;" in the code. Is this just an attempt under the covers to (eventually) avoid misusing JVMCI_CHECK_0 where JVMCI_CHECK_NULL should have been used?
>>> I agree that NULL_WORD has the wrong implication here.
>>> As you correctly surmise, the problem with returning `0` is that it is
>>> a null pointer constant. It would be nice if JVMCI_CHECK_0 could not
>>> be used in a context where a pointer result is expected, and instead
>>> require JVMCI_CHECK_NULL in such cases. That was the point of my
>>> suggestion of using
>>> #define JVMCI_CHECK_0  JVMCI_CHECK_(int(0))
>>> The expression `int(0)` is not a null pointer constant, so won't
>>> implicitly convert to a null pointer.
>>
>> I'm sure I tried something like that when fixing up some misuses of the more general CHECK_0 macro, but it did not help in detecting the misuse.
> 
> Drat, you are right; that doesn't have the desired effect, at least
> with gcc.
> 
> I hadn't noticed some of the evolution of the definition of "null
> pointer constant", and have mostly been looking at C++14 for reference
> lately. The definition (4.10 in all three below) is:
> 
> C++98: an integral constant expression (5.19) rvalue of integer type
> that evaluates to zero.
> 
> C++11: an integral constant expression (5.19) prvalue of integer type
> that evaluates to zero or a prvalue of type std::nullptr_t.
> 
> C++14: an integer literal (2.14.2) with value zero or a prvalue of
> type std::nullptr_t.
> 
> I've been assuming the literal 0 definition. And even so, it seems
> that gcc (at least) is using the C++11 definition with -std=c++14. I
> don't know what clang or Visual Studio do in C++14 mode.
> 
> Rather than using `int(0)`, I think the following would achieve the
> goal of preventing JVMCI_CHECK_0 from being used in a pointer context:
> 
> inline int JVMCI_CHECK_0_value() { return 0; } // Private helper
> #define JVMCI_CHECK_0  JVMCI_CHECK_(JVMCI_CHECK_0_value())
> 
> Is that worth the trouble?
> 

I do not think so. I dislike these macros and i just wanted to make some 
trivial improvements. If we can not agree, I propose we leave the macros 
as they were.

New webrev including copyright year fix proposed by Magnus:
http://cr.openjdk.java.net/~lkorinth/8240110/part6

I keep the old definitions of JVMCI_CHECK_0 although I can not 
understand the dislike to use NULL_WORD.

/Leo