One function
next_token in desgeeko/pdfsyntax
The author described this change as “Fix #2 with support for balanced parentheses inside literals”. It counts as a record because the check below fails on the code as it stood at 28b9d9c9c and passes on 96385155e, with nothing else changed between the two runs.
Projectdesgeeko/pdfsyntax
Fix saved2024-07-20
Sharing licenceMIT · LICENSE
Change size+6 −3
What the code was meant to do, written into the code itself as a docstring
Find next token in raw string starting at some index.
The change
| 57 | 57 | elif search == "LSTRING": | |
| 58 | 58 | if double == b'\\(' or double == b'\\)': | |
| 59 | 59 | i += 1 | |
| 60 | - | else: | |
| 61 | - | if single in b')': | |
| 62 | - | return (h, i + 1, 'STRING') | |
| 60 | + | elif single == b'(': | |
| 61 | + | nested += 1 | |
| 62 | + | elif single == b')': | |
| 63 | + | nested -= 1 | |
| 64 | + | if nested == 0: | |
| 65 | + | return (h, i + 1, 'STRING') | |
| 63 | 66 | elif search == "HSTRING": | |
| 64 | 67 | if double == b'\\<' or double == b'\\>': | |
| 65 | 68 | i += 1 |
The check that tells the two apart
fail→pass·tests/test_tokenization.py::Tokenization::test_literal_string_with_parentheses
Check file tests/test_tokenization.py, taken without changes from the fix and copied onto the older code, so the exact same check runs against both versions.
Origin and history
The code before it28b9d9c9cc74b38c1566ad82bcbd85701f074e3c
Broken version dated2024-06-16
Modulepdfsyntax.objects
Units changednext_token
Fingerprint09410f97ca9161cd
Checked2026-08-18 by goldset/0.1
Every field above is generated by our program. None of it is written by hand.
Other bugs found in desgeeko/pdfsyntax
- 2024-12-29parse_stream_content