3 ms·
I never understood why GUIDs were defined as typedef struct _GUID { DWORD Data1; WORD Data2; WORD Data3; BYTE Data4[8]; } GUID; rather
by pdw 7y ago
I never understood why GUIDs were defined as
typedef struct _GUID {
DWORD Data1;
WORD Data2;
WORD Data3;
BYTE Data4[8];
} GUID;
rather than simply
typedef struct _GUID {
BYTE Data[16];
} GUID;
I get that traditional GUIDs have an internal structure, but it's entirely different than the struct (60-bit timestamp, 4-bit version, 16-bit sequence number, 48-bit MAC address).
- aljarry 7y agoIt'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.
- Sharlin 7y agoThat seems like begging the question. Why it is divided like that in the string representation?
- pdw 7y agoBut 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/quotasrc/src/ncs/nck 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...
- thunderbong 7y agoI think if it was set like that many more programmers would be asking the reverse question - 'Why is it 16 bytes?' and it would be a Stackoverflow wiki question! Maybe this is not the underlying reason, but in my opinion code should be written so that it is understandable and maintainable by future programmers