Repository navigation
Add cbor_structurally_equal for encoding-level item comparison - #408
Merged
Merged
Conversation
Introduces cbor_structurally_equal(), which compares two cbor_item_t values for structural (encoding-level) equality: every aspect of the encoding is significant — integer width, float width, definite vs. indefinite length, chunk boundaries in indefinite strings/bytestrings, and positional order of map entries. This is intentionally stricter than the RFC 8949 data-model equality (where encoding width is invisible and maps are unordered). The function is documented to make this distinction explicit. Includes 36 test cases covering all eight major types and the key edge cases (same value different width, definite vs. indefinite, chunk structure, map ordering, NaN, cross-type). Related to #96 (cbor_map_get and cbor_equal). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rally_equal Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #408 +/- ##
===========================================
- Coverage 100.00% 99.42% -0.58%
===========================================
Files 20 20
Lines 1663 1731 +68
===========================================
+ Hits 1663 1721 +58
- Misses 0 10 +10 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Mar 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cbor_structurally_equal(const cbor_item_t*, const cbor_item_t*)tocommon.h/common.ctest/structurally_equal_test.ccovering all eight CBOR major typesdoc/source/api/item_types.rstDesign rationale
PR #96 proposed a
cbor_equalfunction but left the semantics underspecified. RFC 8949 defines two distinct notions of equality:uint8(1)anduint64(1)are the same integer.uint8(1) ≠ uint16(1).This PR implements structural equality under the name
cbor_structurally_equal, which makes the semantics explicit and avoids surprising callers who might expect data-model behaviour from a function namedcbor_equal. The function is extensively documented to explain what it does and does not compare, and to point callers toward the value accessors (cbor_get_uint64etc.) for data-model comparisons.Notable structural rules that differ from data-model equality:
cbor_structurally_equaluint8(1)vsuint16(1)false— encoding width differsfloat2(1.5)vsfloat4(1.5)false— float width differsfalsefalsefalse— positional comparisonfalse— bitwise float comparisonNULL inputs are programming errors; assertions fire in debug builds (consistent with the rest of the libcbor API).
Test plan
ctest -R structurally_equal_testpasses (36/36)bash clang-format.shproduces no diff🤖 Generated with Claude Code