You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.
It's important for content-addressing to have the same endianness for We should either have a generic rule or have every codec should have a section about endianness.
I propose that we write in a general document for all codecs that endianness is expected if data is serialized as fixed sized integers or floats. Varints are a special case. I consider them being their own type, but effectively they are big-endian (though I'm not sure if their big-endianness should be spell that out explicitly).
The text was updated successfully, but these errors were encountered:
I think that this probably belongs in the codec docs themselves rather than a dedicated doc. It's quite different from something like UTF-8 questions that get into in-memory and API issues. Endianness just needs clarity when converting to and from bytes and so far we get to rely on upstream specs, but as we work more on our own codecs then this absolutely needs to be in those. I'm just not sure it rises to the level of needing its own doc?
I'm just not sure it rises to the level of needing its own doc?
I rather meant "top-level" doc than "own doc" in the sense that if it turns out to be the same for all our codecs, then we can mention it at a single place spanning all codecs, rather then putting into each of them. But that's just a minor thing, we can do whatever works best :)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's important for content-addressing to have the same endianness for We should either have a generic rule or have every codec should have a section about endianness.
I propose that we write in a general document for all codecs that endianness is expected if data is serialized as fixed sized integers or floats. Varints are a special case. I consider them being their own type, but effectively they are big-endian (though I'm not sure if their big-endianness should be spell that out explicitly).
The text was updated successfully, but these errors were encountered: