Pitfall (unspecified?) behavior of MemorySegment.mismatch. JDK 21

[Roman Stoffel]

Hi

First, I'm not sure if I am at the right place, let me know if I'm wrong.

I was trying to compare different sections of Memory and used
MemorySegment.mismatch.
My program got unexpected results and failed.

The issue boiled down to that I compared the same MemorySegment with
itself, but on different range. Example program, which demonstrates the
issue:

public class UnexpectedMismatchBehavior {
    public static void main(String[] args) {
        byte[] exampleData = new byte[]{1, 2, 3, 4,
                -1, -1, -1, -1,
                1, 2, 8, 8,
                -1, -1, -1, -1};
        // In the real world, this is a large memory mapped file
        MemorySegment memory = MemorySegment.ofArray(exampleData);
        // In the real app these are of course dynamic
        int searchTermOffset = 0;
        int len = 4;

        int checkOffset = 8;

        long missMatch = MemorySegment.mismatch(memory,
searchTermOffset, searchTermOffset+len, memory, checkOffset,
checkOffset+len);
        int debug = Arrays.mismatch(exampleData,searchTermOffset,
searchTermOffset+len,exampleData, checkOffset, checkOffset+len);
        if(missMatch == -1){
            System.out.println("Unexpected match!!!");
            System.out.println("Array.mismatch gives: " + debug);
            throw new Exception("What, should not match?");
        } else{
            System.out.println("Missmatch, as expected");
        }
    }
}


Overall, I would expect the same behavior as Arrays.missmatch.

The cuprid seems this check in the implementation:

AbstractMemorySegmentImpl.mismatch(...)
...

if (dstImpl == srcImpl) {
    srcImpl.checkValidState();
    return -1;
}

The current behavior is in my opinion problementatic.
I consider it a bug. Because I get the same return value as if there
would be no match, the program

continues on with the wrong value.

What would instead expect:

- Best would be if it behaves like Arrays.missmatch

- Second best option: It throws an exception.

- Last option: Mention the limitation in the JavaDoc: But still many
bugs will be written because

  the 'fine' print isn't read.

Best regards

Roman Stoffel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240110/a667ad98/attachment.htm>