RFR: 8240110: Improve NULL

[Leo Korinth]

On 15/04/2020 07:45, David Holmes wrote:
> Hi Leo,
> 
> Before I look at the webrev one query ..
> 
> <trimming>
> 
> On 14/04/2020 11:53 pm, Leo Korinth wrote:
>> On 06/04/2020 01:37, David Holmes wrote:
>>>> I could change CHECK_0 to use NULL_WORD though and if I do, I get 
>>>> compiler errors. CHECK_0 is used for both pointers and integral 
>>>> zeroes and types that implicitly converts from either. What the 
>>>> original thought was is unclear to me; is CHECK_0 to be used to 
>>>> return things convertible from pointers? If so, what is CHECK_NULL for?
>>>
>>> No CHECK_0 is intended for int-returning functions (which would also 
>>> extend to intptr_t).
>>
>> It might be intended for it, but it is not used in such a way 
>> (therefore my remark on compile failures when using NULL_WORD)
>>
>> I will do no change here.
> 
> Please explain what you mean by "it is not used in such a way". Other 
> than a few misuses in ./share/jvmci/jvmciCompilerToVM.cpp where it is 
> used for jboolean and the jobject case you are fixing, it is used in 
> methods that return jint, jbyte, jlong ...
> 
> Thanks,
> David
> -----

You mentioned in an earlier mail that the problems I fixed in 
JVMCI_CHECK_NULL should also be observed in CHECK_NULL. I answered that 
was not true because it was used differently. Though if I where to 
redefine CHECK_0 in the same way as i redefined the JVMCI counterpart I 
would get compile time errors. That is, CHECK_0 can not be defined more 
stringently to return an integral zero as call-sites rely on the 
(convertible) zero literal; the macro is thus used in (IMO) the wrong way.


What I tried to say was that I have done /no/ changes for CHECK_0 (or 
the call-sites of it) as I did not want to follow that rabbit hole, I 
only updated JVMCI_CHECK_0 as it was a minimal change. I did cut out too 
much of the mail conversation context for that to be understood, sorry.

/Leo