Skip to content
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

CBOR/MessagePack is not read until the end #505

Closed
nlohmann opened this issue Mar 13, 2017 · 3 comments
Closed

CBOR/MessagePack is not read until the end #505

nlohmann opened this issue Mar 13, 2017 · 3 comments
Assignees
Labels
aspect: binary formats BSON, CBOR, MessagePack, UBJSON solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Milestone

Comments

@nlohmann
Copy link
Owner

nlohmann commented Mar 13, 2017

When reading a binary vector like 0xf9, 0xff, 0xff, 0x4a and interpret it as CBOR, the first three bytes are a half-precision floating-point number (NaN, see #504). The parser will return this number and won't read the last byte.

Example program:

#include "json.hpp"

using json = nlohmann::json;

int main()
{
    std::vector<uint8_t> vec = {0xf9, 0xff, 0xff, 0x4a};
    std::cerr << json::from_cbor(vec) << std::endl;
}

I would like to discuss how to cope with such a situation:

  • Leave it as is?
  • Throw an exception indicating the vector has not been read completely?
  • Continue parsing at this value if the function is called another time. (OK, maybe not exactly this function, but maybe a streaming function.)

Related to #477 #367.

@nlohmann nlohmann added state: help needed the issue needs help to proceed state: please discuss please discuss the issue or vote for your favorite option labels Mar 13, 2017
@TurpentineDistillery
Copy link

The audience for discussion here is likely severely limited.
Is this situation similar to parsing json from a stream containing "0123"... where a valid parse can stop at "0", or parse "0123", interpret as invalid, and throw? If so, throwing is best I think.

@nlohmann nlohmann added the aspect: binary formats BSON, CBOR, MessagePack, UBJSON label Mar 28, 2017
@nlohmann
Copy link
Owner Author

nlohmann commented May 8, 2017

Meanwhile, I also think throwing is best, because we would not implement an operator>> where one could expect that the conversion ends once a value has been read.

@nlohmann
Copy link
Owner Author

Opened #623 as place to discuss the structure of the parsing functions.

nlohmann added a commit that referenced this issue Aug 16, 2017
Added a parameter to control whether parsing CBOR and MessagePack must completely consume the input.
@nlohmann nlohmann removed state: help needed the issue needs help to proceed state: please discuss please discuss the issue or vote for your favorite option labels Aug 16, 2017
@nlohmann nlohmann self-assigned this Aug 16, 2017
@nlohmann nlohmann added this to the Release 3.0.0 milestone Aug 16, 2017
nlohmann added a commit that referenced this issue Aug 16, 2017
The CBOR and MessagePack parsers now expect the input to be read until the end. Unless the new parameter "strict" is set to false (it is true by default), an exception is raised if the parser ends prematurely. This is a breaking change as the parsers ignored unread input so far.

Furthermore, the offset/startIndex paramter introduced in #462 was removed as this behavior can be mimicked with an iterator range. For instance, instead of calling "from_cbor(vec, 5);", you can write "from_cbor({vec.begin()+5, vec.end()});".
@nlohmann nlohmann added the solution: proposed fix a fix for the issue has been proposed and waits for confirmation label Aug 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aspect: binary formats BSON, CBOR, MessagePack, UBJSON solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

No branches or pull requests

2 participants