Repository navigation
ROB: Do not crash when a destination tree node entry is not an array - #4039
stefan6419846 merged 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4039 +/- ##
=======================================
Coverage 98.04% 98.05%
=======================================
Files 57 57
Lines 11225 11232 +7
Branches 2114 2116 +2
=======================================
+ Hits 11006 11013 +7
Misses 122 122
Partials 97 97 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
As a general consideration: Are all of these cases issues on our side or spec violations? I am asking because in theory we would have to differentiate between strict and non-strict mode if there are spec violations. |
|
They are spec violations - §7.9.6 says a name tree node's /Names and /Kids shall be I kept them as warnings rather than adding a strict branch because the surrounding Happy to raise these in strict mode if you would prefer that, but it felt like a |
A name tree node holds its entries under /Names or /Kids, and both are read straight
into a cast without checking what came back. If either is not an array, reading the
named destinations crashes: /Names as a number fails on len(), /Names as a string
fails on get_object(), and /Kids as a number fails when the loop tries to iterate it.
This sits right next to the /Dests guard from #4020 and behaves the same way - the
entry is logged and no destinations are returned, instead of the whole document
becoming unreadable.
Tests cover the container itself being wrong. The existing non_array_value test
already covers a bad element inside a valid array, so that case is untouched.
I could not run the tests that download the corpus locally; the offline suite passes,
1238 tests.
Used Claude (Opus) to help locate and patch this; I reviewed and tested the change.