cbor_get_uint8() returns only positive integers about libcbor HOT 1 CLOSED

Hi @al3xkr,

This is an expected (although somewhat tricky) behavior that follows from how integers are defined in the standard and stored in libcbor. Because CBOR allows 1, 2, 4, and 8 byte integers that are either positive or negative (not unsigned and signed!), there is no way of mapping the full range of negative 8B integers to any standard signed C99 type. The only way to map these values correctly to standard C99 integer types is to use uint8_t through uint64_t.

Specifically, CBOR negative 1B integer can represent values between -1 and -256 inclusive (see http://libcbor.readthedocs.io/en/v0.5.0/api/type_0_1.html#type-0-1), which would underflow an int8_t (representable range -128 through 127).

Therefore cbor_get_uint8 returns uint8_t (http://libcbor.readthedocs.io/en/v0.5.0/api/type_0_1.html#_CPPv214cbor_get_uint8PK11cbor_item_t), as opposed to int8_t. In order to get the 'logical' value represented by the item, you can do e.g.

        cbor_item_t *hkdf_alg = cbor_new_int8();
        cbor_mark_negint(hkdf_alg);
        int abs_i = abs(ECDH_SS_HKDF_256) - 1;
        cbor_set_uint8(hkdf_alg, abs_i);
        int16_t item_value = -1 *  (int16_t) cbor_get_uint8(hkdf_alg) - 1;

Note that int16_t is necessary to avoid the aforementioned underflow.

cbor.me automatically converts the displayed items to the corresponding logical values, so you see -27, but this unfortunately cannot be supported in C until we get a signed integer type that is wider than 64 bits.

Hope this helps,
Pavel

from libcbor.