[atharvmantri]

Summary

Guard the first PEEK_TOKEN(parser) result in the four collection-entry parser functions before reading token->start_mark.

PEEK_TOKEN returns NULL when fetching more tokens fails. The first path in these functions dereferenced that value without the null check used by the subsequent paths, turning malformed/truncated input or an input/allocation error into a null-pointer crash instead of a parser failure.

This fixes the four affected paths:

• yaml_parser_parse_block_sequence_entry
• yaml_parser_parse_block_mapping_key
• yaml_parser_parse_flow_sequence_entry
• yaml_parser_parse_flow_mapping_key

Closes #337.

Testing

• git diff --check
• Verified all four guards are immediately after the first-token fetch and match the existing parser error-handling pattern.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[perlpunk]

I've seen a similar pull request before and I already commented on that, but somehow it's gone. Did someone delete it?

I don't want to repeat myself.
Have you read my comment in the linked issue #337?
Has your LLM also read it?
There is currently no possibility for the token to be NULL in those cases. If you understand the algorithm, the token at that point was already read, otherwise it wouldn't have entered that function.
If you think there is, give me a reproducer please.

[atharvmantri]

Thanks for the careful review. I re-read the discussion on #337 and agree the proposed NULL dereference is not a real bug: when PEEK_TOKEN short-circuits on parser->token_available, the scanner invariant guarantees a queued token, and the failing-fetch path does not leave that flag set. I also do not have a valid reproducer. I’m closing this PR as incorrect rather than preserving a defensive-only change as a bug fix.

[atharvmantri]

Closing after review: the issue report was invalid and no reproducer exists.