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:
The first byte of the 3rd octet is always 80.
Created attachment 226161 [details]
Created attachment 226261 [details]
cvs commit log
Reviewed by: nkinder (Thanks!)
Files: see diff
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
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