OpenJDK 11.0.27 on macOS 15: expression is not an integral constant expression

[Nils Breunese]

Thanks everyone, it looks like adding a patch to replace (-1)<<13 with ~0U<<13 on macOS 15+ worked. Does the PR at https://github.com/macports/macports-ports/pull/28212/files look ok to merge to you?

Nils.

> Op 21 apr 2025, om 02:56 heeft Fred Wright <fw at fwright.net> het volgende geschreven:
> 
> 
> On Sun, 20 Apr 2025, Dave Allured - NOAA Affiliate wrote:
>> On Sun, Apr 20, 2025 at 1:05 PM Fred Wright <fw at fwright.net> wrote:
>>> On Sun, 20 Apr 2025, Dave Allured - NOAA Affiliate via macports-dev wrote:
>>>> On Sun, Apr 20, 2025 at 11:29 AM Joshua Root <jmr at macports.org> wrote:
>>>>> On 21/4/2025 01:27, Nils Breunese wrote:
>>>>>> I created a draft pull request to bump the openjdk11 port to version
>>>>> 11.0.27 (https://github.com/macports/macports-ports/pull/28212), but it
>>>>> looks like this line:
>>>>>> 
>>>>>>      AO_UNUSED_MBZ = (-1)<<13, // options bits reserved for future
>>> use.
>>>>>> 
>>>>>> in src/jdk.pack/share/native/common-unpack/constants.h results in this
>>>>> error on macOS 15:
>>>>>> 
>>>>>>      expression is not an integral constant expression
>>>>>> 
>>>>>> On macOS 13 and 14 the build succeeds without this error.
>>>>>> 
>>>>>> I am not too familiar with C++, but does this seem related to a change
>>>>> in macOS 15? Any idea what should be done to fix the build on macOS 15?
>>>>> 
>>>>> It would be a compiler change rather than a change in the OS. I believe
>>>>> using bitwise shift operators on a negative value has undefined
>>>>> behaviour. The fix would be to express the constant in a well-defined
>>>>> way, for example directly as a hex value, or by shifting a positive
>>>>> value and then negating afterwards. I don't know how this constant is
>>>>> used, so I can't say what would be most appropriate.
>>>> 
>>>> 
>>>> cppreference.com says that is undefined behavior.  That constant is
>>> defined
>>>> as an enum, which I think means only that it needs to be a correctly
>>>> defined integer.  Try something like this:
>>>> 
>>>>    AO_UNUSED_MBZ = (~((1<<13) - 1))
>>> 
>>> No need to elaborately construct a two-complement negation when negation
>>> was never the point in the first place.  Just use:
>>> 
>>>        AO_UNUSED_MBZ = ~0<<13, // options bits reserved for future use.
>>> 
>>> Or, for a more minimal textual change:
>>> 
>>>        AO_UNUSED_MBZ = (~0)<<13, // options bits reserved for future use.
>>> 
>>> Though the parens were never necessary, since the unary operator takes
>>> precedence over the shift.
>> 
>> Thanks for the feedback.  Hmmm.  In my old age I am paranoid about operator
>> precedence, so I tend to throw in parentheses everywhere.
> 
> I sometimes use superfluous parens when the precedence is nonobvious (and especially when it's counterintuitive), but the precedence of unary operators over dyadic operators is so well-known that they really do seem superfluous in this case.
> 
>> What if compiler interprets ~0 as a negative number before examining the
>> shift?  My way is safer.  But I am not trained in C++.
> 
> Point taken.  I should have written:
> 
>         AO_UNUSED_MBZ = ~0U<<13, // options bits reserved for future use.
> 
> Any compiler that interprets ~0U as a negative number is broken. And actual arithmetic negation isn't needed at all.
> 
>> CC this to the mailing list if you like.
> 
> Fred Wright