Skip to content

Documentation review: exceptions from binary-format hardening, and tuple reference types - #5359

Merged
nlohmann merged 2 commits into
developfrom
claude/doc-review-pass-5
Aug 4, 2026
Merged

Documentation review: exceptions from binary-format hardening, and tuple reference types#5359
nlohmann merged 2 commits into
developfrom
claude/doc-review-pass-5

Conversation

@nlohmann

@nlohmann nlohmann commented Aug 4, 2026

Copy link
Copy Markdown
Owner

Summary

Documentation corrections found while auditing everything merged into develop since #5271, and then re-reviewing the release-notes draft against the code.

1. Exceptions from the binary-format hardening round. #5274, #5284, #5287 and #5332 added input-validation rejections; only #5314 updated exceptions.md. Two entries had become claims the code contradicts:

2. Which types may be referenced in a tuple extraction. The note I added in #5271 said a referenced type must be one the library stores "or an arithmetic type it can convert to/from". That parenthetical is wrong: is_compatible_reference_type requires an exact match against the stored types, so std::tuple<int&> is rejected by static_assert — the library stores number_integer_t (std::int64_t), and there is no int to bind to. Only the by-value case is permissive. Corrected to list the eight admissible types, give the int& counter-example, and separate the two cases.

Does this break the public API?

No. Documentation-only — no header, behavior, or ABI change.

Test plan

  • Every new example message copied verbatim from the originating PR's regression tests (unit-bson.cpp, unit-cbor.cpp, unit-bjdata.cpp).
  • Generalized descriptions checked against binary_reader.hpp on develop for which formats actually throw each code.
  • Tuple claim verified against is_compatible_reference_type in type_traits.hpp and the static_assert in from_json.hpp, cross-checked with the reference tests in unit-constructor1.cpp.
  • All new relative links resolve to existing files.

🤖 Generated with Claude Code

A round of binary-format input validation (#5274, #5284, #5287, #5332)
added new failure modes without updating exceptions.md, and left two
descriptions factually narrower than the code:

- parse_error.110 said "CBOR or MessagePack"; BSON and UBJSON also
  throw it. Generalized, and added the BSON EOF example (#5332).
- parse_error.112: added the BSON document-size mismatch example
  (#5287).
- parse_error.113 said "while parsing a map key", but its own existing
  UBJSON char example already contradicted that. Broadened to cover
  invalid length specifications, and added the negative-string-length
  example (#5284).
- out_of_range.408 said "of an UBJSON array or object"; CBOR now throws
  it too (#5274). Generalized and added both CBOR examples.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
The note added in #5271 said a referenced type must be one the library
stores "or an arithmetic type it can convert to/from". The parenthetical
is wrong: is_compatible_reference_type requires an exact match against
the stored types, so std::tuple<int&> is rejected by static_assert even
though int converts fine as a value. Only the value case is permissive.

Spell out the eight admissible types, give the int& counter-example, and
separate the reference restriction from by-value conversion.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
@nlohmann nlohmann changed the title Documentation review: document exceptions from the binary-format hardening Documentation review: exceptions from binary-format hardening, and tuple reference types Aug 4, 2026
@nlohmann nlohmann added the 🚀 ready to merge Ready to merge - just waiting for CI to complete. label Aug 4, 2026
@nlohmann nlohmann added this to the Release 3.13.0 milestone Aug 4, 2026
@nlohmann
nlohmann merged commit 173f2a7 into develop Aug 4, 2026
143 of 155 checks passed
@nlohmann
nlohmann deleted the claude/doc-review-pass-5 branch August 4, 2026 06:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation M 🚀 ready to merge Ready to merge - just waiting for CI to complete.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant