3 ms·
If you're passing around the string representation, then endianness isn't an issue, sure. But you need to care about it if you store UUIDs efficiently as bytes
by thwarted 11y ago
If you're passing around the string representation, then endianness isn't an issue, sure. But you need to care about it if you store UUIDs efficiently as bytes
Huh? Strings are stored and transmitted as bytes, there is no need to interpret the subfields as any given endianness if the whole thing is stored as 16 bytes.
- MaulingMonkey 11y agoThe typical string/text representation of a UUID is 36 bytes (16 bytes x 2 (hex encoding) + 4 (dashes). Or more if you want to include the NUL terminator, enclosing {}s, a length prefix, or whatever else. Alternatively you can interpret the hexadecimal encoding of the subfields to raw values, and compact things into a single 16 byte / 128-bit value, which I'm assuming is what's being referred to by "storing UUIDs efficiently as bytes". To perform this compacting requires some interpretation - if only from hexadecimal to bytes. In implementing this, you might feed the entire first subfield to your hex parsing function. The result, however, will be an integer with more bits than a byte, at which point you need to care about endianness. You can choose to instead parse two hex characters as a time and treat each as a byte. You could argue that this is "not" interpreting the subfield as any given endianness - but this is semantically identical to interpreting the field as big endian, so I'd argue that you are.
- JoeAltmaier 11y agoThere is no compacting to do, if the uuid is always and forever a 16-byte sequence. E.g. as a resource, or a handle, or a channel id etc.