Skip to content
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

Why is MsgPack big endian? #172

Closed
DaveVdE opened this issue Apr 16, 2014 · 3 comments
Closed

Why is MsgPack big endian? #172

DaveVdE opened this issue Apr 16, 2014 · 3 comments

Comments

@DaveVdE
Copy link

DaveVdE commented Apr 16, 2014

Not really an issue per se, but I'm writing a small encoder/decoder and I must say, it's a pain having to tansform all my in-memory representations of ints, floats from little-endian to big-endian.

Is it deliberate? Is it an optimization for smaller (possibly big-endian) mobile platforms? I care to know.

@frsyuki
Copy link
Member

frsyuki commented Apr 16, 2014

It's because a lot of standard network protocols use big-endian. "Network byte order" is big-endian. My design choice was to follow the traditional convention because I hadn't believe which endian becomes the majority when I designed the format. One practical benefit is that we can use portable and fast macros such as htons(3) or htonl(3) to convert host byte order to network byte order.

@frsyuki frsyuki closed this as completed Apr 16, 2014
@DaveVdE
Copy link
Author

DaveVdE commented Apr 16, 2014

Thank you.

@Tronic
Copy link

Tronic commented Nov 7, 2021

Sorry to post to a very old thread, but just for the public record:

Any new formats should really be little endian. The network convention is dead and no CPUs use big endian anymore. Little endian buffers work directly on current CPUs and are much easier to handle whenever a byte at a time needs processing (avoids some backwards for loops that you need with big endian).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants