CBOR has two types of integers – positive (which may be effectively regarded as unsigned), and negative. There are four possible widths for an integer – 1, 2, 4, or 8 bytes. These are represented by
cbor_int_width
Corresponding cbor_type |
CBOR_TYPE_UINT |
Number of allocations | One per lifetime |
Storage requirements | sizeof(cbor_item_t) + sizeof(uint*_t) |
Note: once a positive integer has been created, its width cannot be changed.
Corresponding cbor_type |
CBOR_TYPE_NEGINT |
Number of allocations | One per lifetime |
Storage requirements | sizeof(cbor_item_t) + sizeof(uint*_t) |
Note: once a positive integer has been created, its width cannot be changed.
Due to their largely similar semantics, the following functions can be used for both Type 0 and Type 1 items. One can convert between them freely using the conversion functions.
Actual Type of the integer can be checked using item types API <item-types>
.
An integer item is created with one of the four widths. Because integers' storage is bundled together with the handle, the width cannot be changed over its lifetime.
Warning
Due to the fact that CBOR negative integers represent integers in the range [ − 1, − 2N], cbor_set_uint
API is somewhat counter-intuitive as the resulting logical value is 1 less. This behavior is necessary in order to permit uniform manipulation with the full range of permitted values. For example, the following snippet
cbor_item_t * item = cbor_new_int8();
cbor_mark_negint(item);
cbor_set_uint8(0);
will produce an item with the logical value of − 1. There is, however, an upside to this as well: There is only one representation of zero.
cbor_build_uint8
cbor_build_uint16
cbor_build_uint32
cbor_build_uint64
cbor_get_uint8
cbor_get_uint16
cbor_get_uint32
cbor_get_uint64
cbor_set_uint8
cbor_set_uint16
cbor_set_uint32
cbor_set_uint64
cbor_int_get_width
cbor_mark_uint
cbor_mark_negint
cbor_new_int8
cbor_new_int16
cbor_new_int32
cbor_new_int64