4 ms·

> No, endianness need not mean anything, when you are using uuids for your own purposes. Go ahead and identify a resource by this id. When it is returned to you

> No, endianness need not mean anything, when you are using uuids for your own purposes. Go ahead and identify a resource by this id. When it is returned to you, it will be as you sent it. No matter what (pointless) swapping and unswapping was done by the other participant. They will return the string the same as they got it (or they have a bug). 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. > To have endianness implies scalar subfields, which implies meaningful values in those fields. This goes back to when the fields had meaning (mac address, timestamp and so on). Nowadays they are random bytes and the breakdown into scalar parts has no useful purpose. Even if you're only using random UUIDs, you need to worry about this, because UUIDs always contain a version and variant number. > Now, you can print UUIDs any way you like. And if you print them different places with different rendering libraries they can look different, sure. Don't confuse that with the underlying value, which is a random string. The string is only mostly random. It contains version information.

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 ago
  The 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 ago
    There 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.

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 ago
The 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 ago
  There 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.