On: How many ways are there to sort GUIDs?

[aljarry]

It's divided exactly as it is in string representation: 4 bytes time_low, 2 bytes time_mid, 2 bytes time_hi_and_version and then: other stuff - 8 bytes.

[pdw → aljarry]

But the string representation has five fields, not four.

There might be an interesting story in tracing the history of GUIDs through the ages...

I found some 1987 code dealing with UUIDs here: https://stuff.mit.edu/afs/athena/astaff/project/opssrc/quota...

They seem to have originated as a 64-bit "uid"s:

    struct uid_t {
        u_long clockh;
        u_int clockl: 4;
        u_char extra: 8;
        u_long node: 20;
    };

Then the 1987 version seems to have been something like this (with the reserved field ignored in the string representation!)

    struct uuid_$t {
        u32 time_high;
        u16 time_low;
        u16 reserved;
        u8 family;
        u8 host[7];
    }

And I guess that's pretty close to the current struct...

[pdw → pdw]

And to complete the story, I'm guessing that that old struct likely got serialized in the DCE protocol as dword/word/word/bytes, so the struct layout remained unchanged to maintain compatibility, even as the definition of an UUID evolved...

[aljarry → pdw]

Nice find!

[Sharlin → aljarry]

That seems like begging the question. Why it is divided like that in the string representation?