People, this thread (from Dec 2011) was never properly concluded. > > On Thu, 15 Dec 2011 15:14:20 -0200, Adriano dos Santos Fernandes > > <adrian...@gmail.com> wrote: > >> There is no UUID "binary representation" in the RFC. There it's just a > >> formated string. > > Yes there is a binary representation defined in > > http://www.ietf.org/rfc/rfc4122.txt in section 4.1.2. It also explicitly > > says that bytes should be in network byte order (aka big-endian). > > Thanks! > > So indeed we're generating invalid binary representation currently, due > to the endian issue.
That's right, the problem is in GEN_UUID, not in the conversion functions. Currently, even after the fix on Posix, our GenerateGuid() functions return the fields in host order, while they should be in network order (MSB always first). For most of the fields this isn't a problem, because they are random anyway. Of the two fields that aren't random, one - guid->data4[0] - is byte-sized, so no problem there either. But the other one - guid->data3, or time-high-and-version - is a two-byte word. The 'version nibble', which is always 4 in our case, is the most significant nibble. This means that it should always come first in any external representation, whether it be the 36-char hyphenated ASCII string or the 16-char 'binary' OCTETS string. Maintaining network order is even more important because Firebird databases are supposed to be transportable between architectures. However, in the current situation the version number winds up in the 7th byte on high-endian systems (correct) and in the 8th byte on little-endian systems (incorrect). Even if this difference were in itself acceptable (which it isn't), transportation to different-endian systems would mess everything up because there is no way that the engine can tell if a certain 16-char OCTETS string represents a UUID or not. After all, it's just a string, not a native GUID type. The "repair" functions CHAR_TO_UUID2 and UUID_TO_CHAR2 don't fix this problem. They only make things more complicated and they introduce new risks. For instance, if you restore a database containing CHAR(16) uuids generated on a different-endian system, UUID_TO_CHAR2 will produce a non-compliant string. So once more, I strongly suggest: - Fix GEN_UUID by making GenerateGuid() return the time-high-and-version word in network order. That's all it takes! - Drop CHAR_TO_UUID2 and UUID_TO_CHAR2 before the final release of Firebird 2.5.2. - Keep CHAR_TO_UUID and UUID_TO_CHAR as they are, except that UUID_TO_CHAR may still need the small change that UUID_TO_CHAR2 already underwent (output lower case a..f instead of upper case). Kind regards, Paul Vinkenoog ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
