RFR: 8240110: Improve NULL

[David Holmes]

On 20/04/2020 10:14 pm, Leo Korinth wrote:
> 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

No further comments from me.

Thanks,
David

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