Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Byte ordering wrong? #1

cbsmith opened this Issue Apr 22, 2014 · 4 comments


None yet
2 participants

cbsmith commented Apr 22, 2014

I could be mistaken, but I believe your code will only have the byte ordering of the raw 128-bits correct on a big endian platform.


otoolep commented Apr 23, 2014

Can you point at a specific line of code that this might be true about?

cbsmith commented Apr 28, 2014

For example, you record the time as:

upper_ = (uint64_t) time_low << 32;

Which means the byte order of those 4 bytes will be dependent on the byte ordering of uint64_t (which will be different depending on the endianess of the platform), but the RFC states those 32-bits must be in big endian order. I think you need to do something like:

upper_ = ((uint64_t) htonl(time_low)) << 32;

Better still is probably to represent the uuid as a sequence of bytes and use Rob Pike's approach to ensuring endian correctness: http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html


otoolep commented Apr 28, 2014

@cbsmith -- thanks, it seems you're right. I actually found some other production-level code I had written elsewhere that used a copy-n-pasted copy of some of this code, and it is making htonX calls -- I must have noticed it myself.

Yeah, the code in this repo needs some tweaking.

otoolep added a commit that referenced this issue Mar 30, 2016


otoolep commented Mar 30, 2016

Should be fixed now, 2 years later.

@otoolep otoolep closed this Mar 30, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment