-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional Little Endian support #45
Comments
Why is it big endian by default anyway? |
@cmr: something about network byte order. Was probably a mistake. In the next breaking change I'll likely fix it. |
Looking forward to this as well. It looks like RFC 213 is a good while from being stabilised due to uncertainty re: integer fallback, so maybe providing an explicit endianness parameter (or type parameter), or even |
What would you think about having the default methods use big-endian, but have an module with endian-choice methods? once 213 lands, it would be easy to deprecate that module, but in the meantime, it wouldn't hurt new users that don't care about endianness. Or maybe choosing endianness isn't that big of a deal and we should just make everyone do it until default method parameters land? |
I'd be using this too. I'd be happy with a temporary separate module. |
There's a few equally valid choices here; I personally think it's also important to be able to serialise with native endianness (use case: serialising a sequence of structs to disk and them reading them back via python/numpy or other process on the same box/cpu which would use the native byte order by default). Off top of my head, I would probably expect a binary serialisation library to use native byte order unless explicit endianness is specified by the user. This has most chances to work for careless cross-process communication. Second best would be little endian since that's what all Intel CPUs are... most unexpected would probably be big endian (for general-purpose encoding/decoding, that is). I wouldn't mind having to provide endianness explicitly though, until 213 lands (if it lands); then it's a separate choice of selecting a sensible default :) |
Honestly I'm leaning towards explicit endianness right now. It doesn't seem like a huge hit to usability and makes it pretty obvious what's going on. |
I'm just hoping that I don't get hit with bugs from people using different endianness for encoding and decoding... |
In C, there is a slight advantage to using "network byte order" aka big endian because you must write every endian conversion manually, so if you leave one out then it breaks on your little endian development machine, but this does not apply to Rust. In Rust, one should probably specify the endianness in a type parameter, not sure all type parameters accept defaults though. |
cf. #103 |
Once RFC 213 is implemented, we should allow optional endiannes to be added to the bincode encoders and decoders.
The text was updated successfully, but these errors were encountered: