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

[Fred Wright]

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