rdf: fix end pointer guard checking the wrong slice in snippet range parsing

[arpitjain099]

While reading through the RDF snippet parser I noticed the end pointer guard in setSnippetRangeFromNode checks the wrong slice:

endPointerTriples := rdfwriter.FilterTriples(associatedTriples, &node.ID, &PTR_END_POINTER, nil)
if len(startPointerTriples) != 1 {
    return fmt.Errorf("range object must be associated with exactly 1 endPointer, got %d", len(endPointerTriples))
}
endRangeType, end, err := parser.getPointerFromNode(endPointerTriples[0].Object, si)

It's pretty much self-evidencing: the error message says endPointer and formats len(endPointerTriples), but the condition reads startPointerTriples, which the block right above has already validated as exactly 1. So the guard can never fire, and endPointerTriples[0] on the next line indexes whatever's there, empty slice or not.

To actually reach it you need a range node that clears the earlier checks (exactly 3 associated triples, exactly 1 rdf:type, exactly 1 startPointer) while having no endPointer. A third triple with some other predicate does it:

<j.0:StartEndPointer>
    <j.0:startPointer>
        <j.0:ByteOffsetPointer>
            <j.0:reference rdf:resource="...#SPDXRef-DoapSource"/>
            <j.0:offset>310</j.0:offset>
        </j.0:ByteOffsetPointer>
    </j.0:startPointer>
    <rdfs:comment>range without an end pointer</rdfs:comment>
</j.0:StartEndPointer>

That panics with index out of range [0] with length 0 instead of returning the error it meant to. Since RDF input is generally untrusted, a malformed document takes down the caller rather than getting a parse error back.

The fix is the one-line change to test endPointerTriples. The same line is wrong in both v2_2 and v2_3, so both are here in one PR.

On the test side: TestCase 4 in each file is labelled "triples with 0 endPointer" but it was actually built with two endPointers and zero startPointers, so it tripped the startPointer guard and returned early. That's why the branch never got caught. I rewrote it to be a real 0-endPointer case, which reproduces the panic on main and passes with the fix. TestCase 3 still covers the missing-startPointer path it duplicated.

Verified with go test ./..., all green. Reverting just the two source lines makes the two updated cases panic, so the tests do cover the change.

[kzantow]

👍