On 03/26/2014 06:00 AM, Przemyslaw Marczak wrote:
Hello Stephen, Thanks for review again:)
On 03/25/2014 08:12 PM, Stephen Warren wrote:
On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote:
Changes in lib/uuid.c to:
- uuid_str_to_bin()
- uuid_bin_to_str()
New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows.
String byte: 0 36 String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx string UUID: be be be be be string GUID: le le le be be
This patch also updates functions calls and declarations in a whole code.
diff --git a/lib/uuid.c b/lib/uuid.c
+void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str,
uuid_str_t str_format)
- static const u8 le[16] = {3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11,
12, 13, 14, 15};
- const u8 uuid_char_order[UUID_BIN_LEN] = {0, 1, 2, 3, 4, 5, 6,
7, 8,
9, 10, 11, 12, 13, 14, 15};- const u8 guid_char_order[UUID_BIN_LEN] = {3, 2, 1, 0, 5, 4, 7,
6, 8,
9, 10, 11, 12, 13, 14, 15};These are really more binary data order than char order, since each one of the bytes pointed at by entries in these arrays ends up being 2 characters. s/char/bin/ in the variable names perhaps?
Yes, you are right. But according to the specification UUID and UUID bin format are always in big-endian - only bytes in some STRING blocks have different order. This works in two ways but to be consistent with specification I called this as "uuid_char_order". And this is directly used by sprintf: "sprintf(uuid_str, "%02x", uuid_bin[char_order[i]]);".
That doesn't make much sense.
If I have 2 bytes stored in memory as:
0xaa 0x55
... and sometimes the string representation of them is aa55 and sometimes 55aa, then *by definition*, that's interpreting the binary data as BE vs LE. The binary data is not always BE.
The only exception would be if for bytes in memory 0xaa 0x55 the 16-bit integer/numerical (in-register) value was always 0xaa55 (BE), yet the string representation of that integer was sometimes aa55 and sometimes 55aa. However, that's not how integer->string conversion works. Different string representations of the binary data would only be possible if the binary data isn't an integer but rather a string of bytes, yet endianness has no meaning for data that is natively a string of bytes, only for larger values that have been serialized into a string of bytes.