| CARVIEW |
Arbitrary-Exponent Numbers
This document registers tags for arbitrary-exponent numbers in Concise Binary Object Representation (CBOR) (ref. 1).
- Tag: 264
- Data item: array
- Semantics: Decimal fraction with arbitrary exponent
- Tag: 265
- Data item: array
- Semantics: Bigfloat with arbitrary exponent
Introduction
The CBOR specification already defines two tags for arbitrary-precision floating-point numbers: tag 4 for decimal
fractions, and 5 for bigfloats. But unfortunately, both tags limit the exponent to major types 0 and 1 (about 65 bits), and some number formats,
notably the one used in JavaScript Object Notation (JSON, ref. 2), don't have a theoretical limit on exponents.
For example, it would be impractical to serialize the JSON number 10e+99999999999999999999 in tag 4, or the number 10e-99999999999999999999
in tag 4 without loss of information, since in both cases, the exponent doesn't fit the range of major types 0 or 1.
The tags defined here are intended to make it possible to serialize numbers like these by allowing the exponent to be
a big integer.
Detailed Semantics
Tag 264 has the same semantics as tag 4, except that the exponent can also be a bignum (major type 6, tag 2 or 3).
Tag 265 has the same semantics as tag 5, except that the exponent can also be a bignum (major type 6, tag 2 or 3).
If a number's exponent is less than 164, and not less than -(164), an implementation may use tag 4 or 5 instead, but this behavior is not required.
A CBOR decoder can treat data items with tag 264 or 265 that don't meet the criteria above as an error, but this specification doesn't define how a CBOR implementation ought to behave in this case. Section 3.4 of RFC 7049 (ref. 1) details this kind of error-handling behavior.
Security Considerations
Decimal fractions and bigfloats allow encoding numbers with exponents that are extremely large (tens of thousands or more) or extremely small (negative tens of thousands or less), so large to be unreasonable for most applications.
There are several security concerns with such numbers:
- A decimal fraction or bigfloat with an extremely large exponent resolves to an arbitrary-precision integer with at least as many decimal digits or bits, respectively, and thus often requires as much memory to store. If such a number is converted to an arbitrary-precision integer (such as `BigInteger` in Java, or CBOR's bignum tags), the decoder or application might need to allocate much more memory than usual. Generally, for extremely large exponents, a decimal fraction with a positive exponent requires at least about 3/10 the value of the exponent in bytes of memory to store, so that, for example, the decimal fraction 75e+9000000 requires about 3 megabytes of storage to an arbitrary-precision integer. Applications or protocols that support decimal fractions and/or bigfloats might wish to—
- limit the supported range of exponents,
- treat numbers with extremely large exponents as infinity or raise an overflow error on such numbers,
- treat numbers with extremely small exponents as zero or raise an underflow error on such numbers, and/or
- raise a subnormal warning on numbers with exponents close to the minimum supported exponent.
- Operations on decimal fractions and/or bigfloats (such as addition and division) can cause unreasonable memory allocation when a number with a small exponent and a number with an extremely large or extremely small exponent are involved. For example, adding the two numbers 75e+9000000 and 125 results in the exact value of 750000...000125, a number with a mantissa of 750000...000125 and an exponent of 0, thus requiring at least 3 megabytes of storage. To mitigate this problem, applications or protocols that support decimal fractions and/or bigfloats might wish to limit the range of precisions (number of decimal digits or bits) the mantissa can have, and round numbers, if necessary, to fit the precision limits.
References
Ref. 1. Bormann, C. and Hoffman, P. "Concise Binary Object Representation (CBOR)". RFC 7049, October 2013.
Ref. 2 (informative). Bray T., ed. "The JavaScript Object Notation (JSON) Data Interchange Format". RFC 7159, March 2014.
Author
Peter Occil (poccil14 at gmail dot com)
My CBOR home page.
Any copyright to this specification is released to the Public Domain. https://creativecommons.org/publicdomain/zero/1.0/