fix: Fix MemorySegment::Compare to use big-endian byte-order comparison semantics

[lxy-9602]

Purpose

No Linked issue.

Problem

MemorySegment::Compare reads 8 bytes at a time using GetValue<int64_t>() which returns the value in native endianness. On little-endian platforms (x86/ARM), this breaks lexicographic (byte-order) comparison semantics — the most significant byte in memory becomes the least significant byte in the integer, causing incorrect comparison results.

For example, comparing [0x00, 0x01, 0, 0, 0, 0, 0, 0] vs [0x01, 0x00, 0, 0, 0, 0, 0, 0]:

• Expected (lexicographic): first byte 0x00 < 0x01, result should be negative
• Before fix (little-endian native): reads as 0x0100 > 0x0001, result was positive ❌

This is consistent with the existing TODO in the code and aligned with the Java implementation which uses getLongBigEndian().

Fix

• Added GetLongBigEndian() method to MemorySegment that reads 8 bytes and converts to big-endian order using the existing EndianSwapValue() utility from math.h
• Updated Compare() to call GetLongBigEndian() instead of raw GetValue<int64_t>()

Tests

MemorySegmentTest.TestCompare

API and Format

Documentation

Generative AI tooling

Generated-by: Claude-4.7-Opus

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.