Fix precondition violation in parse_key when parsing '[[[' table headers#301
Merged
marzer merged 2 commits intoMay 10, 2026
Merged
Conversation
parse_table_header() consumes the leading '[' (and the second '[' for
array-of-tables headers) and then calls parse_key() unconditionally,
checking only for a closing ']'. When the next character is neither a
bare-key character nor a string delimiter (e.g. a third '[' as in the
input '[[[1]]]'), parse_key() is entered with its documented
precondition violated:
TOML_ASSERT_ASSUME(is_bare_key_character(*cp) || is_string_delimiter(*cp));
In debug builds this aborts; under NDEBUG the macro expands to
__builtin_assume, so the violation is undefined behaviour.
Validate the key starter explicitly in parse_table_header() and raise
the usual parse_error instead. Add regression tests for the malformed
array-of-tables header cases and regenerate the single-header toml.hpp.
Contributor
Author
|
Write me if I should remove the comments from the code |
Owner
Yes, please. These look like classic LLM comment vomit. Otherwise the fix is good 👍🏼 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of the bug
parse_table_header()can callparse_key()with an invalid starting character after consuming a table header prefix.For example, with input like
[[[1]]], the parser consumes the first[and the second[as an array-of-tables header, then entersparse_key()while*cpstill points at the third[. That character is neither a bare-key character nor a string delimiter, so it violates this precondition inparse_key():TOML_ASSERT_ASSUME(is_bare_key_character(*cp) || is_string_delimiter(*cp));In debug builds this hits the assertion and aborts the process instead of returning a normal
parse_error.Reproduction
With a debug clang build this currently fails with:
Similar small cases are
[[[a]]],[[[]], and[[=.Fix
Before calling
parse_key(),parse_table_header()now checks that the next character is a valid key starter.If it is not, the parser reports a normal
parse_errorinstead of enteringparse_key()with a broken precondition.Tests
Added regression tests for malformed array-of-table headers such as:
[[[1]]][[[a]]][[[]][[=Valid table headers and array-of-table headers still parse as before.