The uuid code has this code (where clock_seq is unsigned16 - 2 bytes and uuid->clock_seq_hi_and_reserved is unsigned8 - 1 byte): uuid->clock_seq_hi_and_reserved = (unsigned8)(clock_seq & 0x3F00) >> 8; In this code, the cast to unsigned8 takes precedence over over the shift. So what happens is that (clock_seq & 0x3F00) is first cast to an 8 bit quantity, then shifted by 8 bits. The result is that the value is _always 0_. The code also does this: uuid->clock_seq_hi_and_reserved |= 0x80; You can see this because every nsUniqueID looks like this: XXXXXXXX-XXXXXXXX-80XXXXXXXX-XXXXXXXX The first byte of the 3rd octet is always 80.
Created attachment 226161 [details] diffs
Good catch!
Created attachment 226261 [details] cvs commit log Reviewed by: nkinder (Thanks!) Files: see diff Branch: HEAD Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=330121#c0 This may also be related to https://bugzilla.redhat.com/show_bug.cgi?id=197886 and may explain why the sequence numbers were exhausted so quickly. Without this fix, we only have 256 sequence numbers available. This fix adds another 6 bits. The fix is to mask and shift as an unsigned16 quantity, then cast to unsigned8. Platforms tested: RHEL5 x86_64 Flag Day: no - I think this will only impact new unique IDs that are generated. It will not affect existing unique IDs. Doc impact: no