Codec.CBOR.Cuddle.CBOR.Canonical

A canonical representation of CBOR data items. Two CanonicalTerms compare equal exactly when the underlying CBOR items are equivalent under the extended generic data model of RFC 8949 §3.4.3 — the same notion of equality that determines whether two map keys are duplicates (RFC 8949 §3.1, §5.6).

Differences from Term:

• Major types 0 and 1 are split into CTInt and CTNInt (matching the on-wire structure) instead of overlapping in TInt/TInteger.

• Bignums (tags 2 and 3) whose value fits in [-2^64, 2^64 - 1] are normalized into CTInt / CTNInt (RFC 8949 §3.4.3).

• Definite- and indefinite-length variants are merged: there is no separate constructor for what TBytesI, TStringI, TListI, TMapI represent.

• Maps use Map rather than a list of pairs, so key order is irrelevant.

• TBool and TNull are folded into CTSimple (values 20, 21, 22 per RFC 8949 §3.3).

• THalf, TFloat, TDouble remain distinct constructors: the generic data model treats different float widths as distinct items (RFC 8949 §2).

A negative integer in the range [-2^64, -1]: exactly the values representable by CBOR major type 1 (RFC 8949 §3.1). The range is wider than Int64 on the negative side, so it can't be stored as a plain signed integer.

Convert a cborg Term to a CanonicalTerm.

A CBOR map with duplicate keys is well-formed but invalid (RFC 8949 §5.6). Canonicalizing such a map is not currently supported and raises an error. This only arises in the niche case of a duplicate-keyed map nested in a position the validator does not otherwise reject (e.g. a map used as a map key). If you hit this, please open an issue.