-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect parsing of indefinite length CBOR strings. #961
Comments
I can confirm your observation, and I also checked with the CBOR playground: I honestly must have missed that part and implemented indefinite length strings just like maps and arrays. Thanks for checking the code so thoroughly! I think your fix is valid - I just have the feeling there is an STL algorithm ( |
Simply appending to the string directly certainly is simpler, and only a one line change: case 0x7F: // UTF-8 string (indefinite length)
{
string_t result;
while (get() != 0xFF)
{
unexpect_eof();
result.append(get_cbor_string());
}
return result;
} Indefinite length strings are probably such a rare case that doing things like reserving capacity to save allocation as the first one does... premature optimization and therefore evil. 😜 |
With the secondary array, you're going to end up with guaranteed two string copies, one allocation, and one deallocation per string in the indefinite string (unless those strings fit in the small string optimization). If you do it as.... as @johnfb just wrote as I was writing this... you will have the same count as upper bound, and better performance in general. |
Thanks! And after all, you would also need allocations to copy the strings into the vector. |
Kudos for @gregmarr to always be so fast ;) |
Alright - I'll add a fix later today. |
Beside the fix discussed in #961, we also had to re-adjust a test case. It seems that it was failing before, and I "fixed" it to work with the broken implementation...
Thanks everybody! |
I found this library and thought it was very interesting and like a lot about it and decided to brows the source code a little bit. I am thinking I will try using this in my next project. In my browsing I found the following problem:
json/include/nlohmann/detail/input/binary_reader.hpp
Line 946 in 737cffe
According to section 2.2.2 of the CBOR RFC 7049 an indefinite length string is a list of definite length strings terminated by the terminal byte 0xFF. As such the following code snippet should print the same string twice.
But as of version 3.1.0 it prints:
Changing that case to something like:
Fixes it. I'm not sure if this is the way you want to do it though.
The text was updated successfully, but these errors were encountered: