[foreign-memaccess+abi] RFR: 8300201: When storing MemoryAddress.ofLong(0x0000000080000000L), MemorySegment.get is not equal to MemorySegment.set because of the expanded sign [v2]

[Maurizio Cimadamore]

On Thu, 2 Feb 2023 17:41:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update comments for 32-bit platforms
>>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1071:
> 
>> 1069:      * <p>
>> 1070:      * On 32-bit platforms, the given address value will be normalized such that the
>> 1071:      * upper 32 bits of the {@link MemorySegment#address() address} of returned memory segment
> 
> Ah - late to the party. Is "upper bits" correct here? E.g. doesn't it depend on endianness? Perhaps use "most-significant bits?"

I'm partly confusing myself, but we should still draw from javadoc in other areas:
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Long.html#highestOneBit(long)
This seems to use highest-order/leftmost for "uppermost bit" :-)

-------------

PR: https://git.openjdk.org/panama-foreign/pull/774