Flow sequence and comma tokens in keys cause incorrect parse results
Closed this issue · 4 comments
Description
Keys that contain [] or , cause fkYAML to either parse the tree incorrectly or throw parser exceptions.
Reproduction steps
Here is a minimal YAML snippet demonstrating the failures when used along with fkyaml::node::deserialize:
LPUARTUSART?: "dummyValue" # parses OK
LPUART,USART?: "dummyValue" # parses without errors but gives an incorrect tree as a result, it nests "USART?" : "dummyValue" as child of LPUART
LPTIM[23]: "dummyValue" # parse_error: A key separator found without key
Expected vs. actual results
The minimal YAML snippet in question passes validation with multiple validators, and parses correctly with YAML libraries written in Python and Rust.
As a result in all three cases I would expect the key-value pair to parse successfully, to a scalar key and scalar value, rather than just the first.
Minimal code example
No response
Error messages
No response
Compiler and operating system
VS 2022 (both clang-cl and msvc compilers), Win 10
Library version
Validation
- The bug also occurs if the latest version from the
developbranch is used. - I can successfully compile and run the unit tests.
@stephenwhittle
Thanks for your report!
The same issues happened on my environment.
While checking the YAML spec, I realized that I had a wrong idea that flow indicators must not be inside a plain(=unquoted) scalar, by misunderstanding the following part (in the "7.3.3 Plain Style" section):
In addition, inside flow collections, or when used as implicit keys, plain scalars must not contain the “[”, “]”, “{”, “}” and “,” characters. These characters would cause ambiguity with flow collection structures.
So, your expectation is correct.
I'll fix the issues hopefully this weekend.
As a workaround, quoting the second & third keys should resolve them.
Thank you very much! I'm enjoying using the library so far, so will be looking forward to those fixes when they become available. :)
@stephenwhittle
I've fixed the bugs in the PR #276.
Can you confirm if they are fixed on your environment in the latest develop branch?
Yes, this appears to address those specific issues, thank you.
I have a fairly large corpus of YAML files containing these sorts of constructions (unfortunately part of another project, so I can't simply quote the strings), so if I encounter any other edge cases I'll file a separate issue for those.