Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/mkdocs/docs/features/binary_formats/cbor.md

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "Incomplete mapping" warning still lists date/time (0xC0..0xC1), bignum (0xC2..0xC3), decimal fraction (0xC4), bigfloat (0xC5), and expected conversions (0xD5..0xD7) as types that "are not supported and will yield parse errors." That's now only true for the default error handler — under ignore/store these parse fine, same as 0xC6..0xD4/0xD8..0xDB, which were already correctly omitted from this list. Since the PR already updates the "Tagged items" warning just below to say the full 0xC0..0xDB range is tag-handler-dependent, these five bullets should be deleted from the "Incomplete mapping" box to avoid the two warnings contradicting each other.

Original file line number Diff line number Diff line change
Expand Up @@ -181,7 +181,7 @@ The library maps CBOR types to JSON value types as follows:

!!! warning "Tagged items"

Tagged items will throw a parse error by default. They can be ignored by passing `cbor_tag_handler_t::ignore` to function `from_cbor`. They can be stored by passing `cbor_tag_handler_t::store` to function `from_cbor`.
Tagged items (`0xC0`..`0xDB`) will throw a parse error by default. They can be ignored by passing `cbor_tag_handler_t::ignore` to function `from_cbor`. They can be stored by passing `cbor_tag_handler_t::store` to function `from_cbor`.

??? example

Expand Down
11 changes: 10 additions & 1 deletion include/nlohmann/detail/input/binary_reader.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -760,7 +760,13 @@ class binary_reader
case 0xBF: // map (indefinite length)
return get_cbor_object(detail::unknown_size(), tag_handler);

case 0xC6: // tagged item
case 0xC0: // tagged item
case 0xC1:
case 0xC2:
case 0xC3:
case 0xC4:
case 0xC5:
case 0xC6:
case 0xC7:
case 0xC8:
case 0xC9:
Expand All @@ -775,6 +781,9 @@ class binary_reader
case 0xD2:
case 0xD3:
case 0xD4:
case 0xD5:
case 0xD6:
case 0xD7:
case 0xD8: // tagged item (1 byte follows)
case 0xD9: // tagged item (2 bytes follow)
case 0xDA: // tagged item (4 bytes follow)
Expand Down
11 changes: 10 additions & 1 deletion single_include/nlohmann/json.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -11309,7 +11309,13 @@ class binary_reader
case 0xBF: // map (indefinite length)
return get_cbor_object(detail::unknown_size(), tag_handler);

case 0xC6: // tagged item
case 0xC0: // tagged item
case 0xC1:
case 0xC2:
case 0xC3:
case 0xC4:
case 0xC5:
case 0xC6:
case 0xC7:
case 0xC8:
case 0xC9:
Expand All @@ -11324,6 +11330,9 @@ class binary_reader
case 0xD2:
case 0xD3:
case 0xD4:
case 0xD5:
case 0xD6:
case 0xD7:
case 0xD8: // tagged item (1 byte follows)
case 0xD9: // tagged item (2 bytes follow)
case 0xDA: // tagged item (4 bytes follow)
Expand Down
6 changes: 4 additions & 2 deletions tests/src/unit-cbor.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -2529,11 +2529,13 @@ TEST_CASE("Tagged values")
const json j = "s";
auto v = json::to_cbor(j);

SECTION("0xC6..0xD4")
SECTION("0xC0..0xD7")
{
for (const auto b : std::vector<std::uint8_t>
{
0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF, 0xD0, 0xD1, 0xD2, 0xD3, 0xD4
0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5,
0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF, 0xD0, 0xD1, 0xD2, 0xD3, 0xD4,
0xD5, 0xD6, 0xD7
Comment on lines +2532 to +2538

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests only wrap a string value for each new tag byte. Might be worth a case wrapping a binary payload under cbor_tag_handler_t::store to confirm 0xC0-0xC5/0xD5-0xD7 take the same "unwrap, don't treat as subtype" path as 0xC6-0xD4 already do.

})
{
CAPTURE(b);
Expand Down
Loading