UUID生成器问题 [英] UUID generator problem
问题描述
我有一个uuid类,它是一个可移植库的一部分,用下面的代码片段初始化。它在windows下正常工作,但在linux下,
不能正确生成UUID。
uint32 data [4]
data [0] = rng.Get();
data [1] = rng.Get();
data [2] = rng.Get();
data [3] = rng.Get();
data [1] =(data [1]& 0xffffff0f)| 0x40;
data [2] =(data [2]& 0x7fffffff)| 0x40000000;
printf(12345678901234567890123456789012\\\
);
memcpy(uuid,data,16);
for(int i = 0; i <4; i ++)
printf(%04X,data [i]);
printf(\\\
);
for(int i = 0; i <16; i ++)
printf(%02X,uuid [i]);
printf(\\\
);
printf语句是我调试的。
<但是,数字被搞砸了。
为什么底部的4个字节为空?
为什么是第一个uuid打印,不同于最后?
platorm是x86上的64bt linux。这将始终运行在x86小端架构上。
例如。示例输出
<$ c $ p>
第一次运行
12345678901234567890123456789012
B6D2ADAF46CF624A581187F3670BBEE0
AFADD2B6D6E792FB4A62CF4600000000 //为什么不同先前的否?也是最后4个字节未设置???
第二次运行
12345678901234567890123456789012
96D6D234D5602743548FD812A0D96818
34D2D6965B65F32F432760D500000000 //与先前相同的问题
这种转换正在进行中。
这已经解决了。我不在乎endianess。 c>%x %x
指定符期望一个 int
-sized输入被传递,而你似乎传递一个 unsigned char
(isn uuid [i]
is?)。 尝试这样做,看看它是否有帮助: / p>
for(int i = 0; i <16; i ++){
int temp = uuid [i]
printf(%02X,temp);
}
printf(\\\
);
更新 - 新理论
在阅读马修的回答后,我仔细看了一下。
问题是 memcpy
uuid
。您可以将 uint
复制到 uuid
。 uuid
的前4个字节是 data [0]
的小端表示,如所预期的。 / p>
现在一个可以解释其余的理论是 uint32
实际上是8字节长而不是4,将数据
的前16个字节复制到 uuid
,我们按顺序看到:
-
4 LSB的数据[0]
,小尾数 - 4 MSB
data [0]
(junk) -
,little endian
-
数据的4 MSB [1]
(垃圾,由于某种原因全部为零) -
data [2]
和data [3]
没有任何东西。 $ b $
那么什么是 sizeof(uint32)
等于?
I have a uuid class that is part of a portable library that gets initialized with the following piece of code. It works fine under windows, but under linux it's not generating UUID's correctly.
uint32 data[4];
data[0] = rng.Get();
data[1] = rng.Get();
data[2] = rng.Get();
data[3] = rng.Get();
data[1] = (data[1] & 0xffffff0f) | 0x40;
data[2] = (data[2] & 0x7fffffff) | 0x40000000;
printf("12345678901234567890123456789012\n");
memcpy(uuid, data, 16);
for (int i = 0; i < 4; i++)
printf("%04X", data[i]);
printf("\n");
for (int i = 0; i < 16; i++)
printf("%02X", uuid[i]);
printf("\n");
The printf statements are me debugging it.
But, the numbers are messed up. Why are the bottom 4 bytes empty? And why is the first uuid printed, different from the last?
The platorm is 64bt linux on x86. This will always be run on x86 small endian architecture.
e.g. sample output
1st run
12345678901234567890123456789012
B6D2ADAF46CF624A581187F3670BBEE0
AFADD2B6D6E792FB4A62CF4600000000 // why is this different from the previous no?. also the last 4 bytes not set???
2nd run
12345678901234567890123456789012
96D6D234D5602743548FD812A0D96818
34D2D6965B65F32F432760D500000000 // same problem as earlier
Something is going haywire with the conversion.
This has now been solved. I don't care about endianess. The bytes are random anyway!
It appears that the %X
specifier is expecting an int
-sized input to be passed, while you seem to be passing it an unsigned char
(isn't that what uuid[i]
is?).
Try doing this and see if it helps:
for (int i = 0; i < 16; i++) {
int temp = uuid[i];
printf("%02X", temp);
}
printf("\n");
Update - New theory
OK, I looked at it more carefully after reading Matthew's answer.
The issue is memcpy
along with the (unknown) type of uuid
. You copy the uint
s over uuid
. The first 4 bytes of uuid
are the little-endian representation of data[0]
, as should be expected.
Now one theory that could explain the rest is that uint32
is actually 8 bytes long instead of 4, so when you copy the first 16 bytes of data
onto uuid
we see in order:
- 4 LSB of
data[0]
, little endian - 4 MSB of
data[0]
(junk) - 4 LSB of
data[1]
, little endian - 4 MSB of
data[1]
(junk, for some reason all zeroes) - And nothing of
data[2]
anddata[3]
.
So what is sizeof(uint32)
equal to?
这篇关于UUID生成器问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!