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 <f...@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 <f...@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 <j...@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
