nlohmann/json

Description docs/mkdocs/docs/features/binary_formats/messagepack.md states that strings, byte strings, arrays, and objects with more than 4294967295 elements/bytes "can not be converted to a MessagePack value". Nothing in the writer enforces that, and the same page also promises "Any MessagePack output created by to_msgpack can be successfully parsed by from_msgpack". All four size-prefixed cases in write_msgpack end their if/else if chain at std::uint32_t with no final else: value type site largest branch string binary_writer.hpp:554-587 0xDB str 32 array binary_writer.hpp:589-609 0xDD array 32 binary binary_writer.hpp:619-686 0xC6/0xC9 bin 32 / ext 32 object binary_writer.hpp:702-722 0xDF map 32 When N exceeds UINT32_MAX no branch runs, so no header byte is written at all and the writer proceeds straight to the payload. Two failure modes: array / object — the elements are written through real iterators, so to_msgpack() returns successfully with a headerless, corrup

Description write_cbor() serializes object keys by calling itself on the key: json/include/nlohmann/detail/output/binary_writer.hpp Lines 403 to 407 in 8ec98e2 for (const auto& el : *j.m_data.m_value.object) { write_cbor(el.first); write_cbor(el.second); } el.first is a string_t, but the parameter is const BasicJsonType&, so each key is implicitly converted to a temporary basic_json — which heap-allocates a string_t (plus its buffer for keys beyond SSO) — purely to reach the value_t::string case a few lines above. write_msgpack() has the identical pattern. The UBJSON and BSON writers in the same file already do it the direct way, writing the key's characters straight to the output adapter without c

Description RFC 8949 §3.2.3 requires that the chunks of an indefinite-length string be definite-length strings of the same major type: Each chunk of an indefinite-length string is a definite-length string of the same major type. get_cbor_string() and get_cbor_binary() read each chunk by recursing into themselves (binary_reader.hpp:1025-1037 and 1125-1137), and the recursive call re-enters the full switch including the 0x7F/0x5F case. So a chunk may itself be an indefinite-length string, to arbitrary depth, and the library accepts it. The cross-major-type rule is already enforced correctly — a byte-string chunk inside a text string is rejected, and vice versa. It is only the "definite-length" half of the rule that is missing. Secondary effect: because the nesting is unbounded, 0x7F repeated ~50 000 times segfaults. That aspect overlaps with #5104 / #5293, but a depth guard alone would only turn the crash into a clean parse_error — the two-level case below would still be accepted