-
Notifications
You must be signed in to change notification settings - Fork 99
Support 128-bit integers #145
base: master
Are you sure you want to change the base?
Conversation
b07d2b7
to
8bc0bc6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if I want to support big integers. They would be the first supported tagged value, additionally it breaks code that relies on the assumption that big integers are deserialized as bytestrings. (I don't know if there is such code)
Integer(i128), | ||
/// Unsigned integer CBOR numbers. | ||
Unsigned(u128), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like to have two overlapping integer variants (again) because a postive number can now be stored in two different ways.
Ist there something special about 128-bits that you need u128
numbers that do not fit into i128
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there something special about 128-bits that you need u128 numbers that do not fit into i128?
The only issue is with the canonical sort order. Before, i128
could record the sign and magnitude of the largest supported number. Since i128
is the largest data type, the sign isn't recorded independently of magnitude.
Well, it's in accordance with the spec and doesn't much affect the codebase.
Yes, that's a fair point. How about, instead, special-casing the implementation of |
@sfackler What do you think about supporting 128-bit integers in this crate? |
@@ -280,6 +280,33 @@ where | |||
Ok(BigEndian::read_u64(&buf)) | |||
} | |||
|
|||
fn parse_bigint<V>(&mut self, signed: bool, visitor: V) -> Result<V::Value> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it better to separate this as a function rather than just keeping it down?
Is there something that we can do to move this forward? Being unable to serialize a basic Rust type unfortunately makes serde_cbor not usable for me. |
You can pay me to work on this crate. Or you can find a company or team that wants to take over the maintenance of this crate.
128-bit integers aren't part of CBOR (big ints are however) and 128-bit integers weren't part of Rust 1.0 as well. You can always write a custom (de)serializer for your data structures. There is another serde CBOR crate: https://github.com/enarx/ciborium maybe it is right for your use-case. (They handle 128-bit integers.) |
Or you can wait until someone who is interested to pick this up. At least I am not interested in this right now. |
This PR adds support for
u128
andi128
in accordance with §2.4.2 of the CBOR spec.