Paul, Can you say, with less words and more examples, what's wrong and why?
I mean, please run the current code and dump some commands, results and explanations here. I didn't ignored Mark's saying "It also explicitly says that bytes should be in network byte order (aka big-endian)" and my code was committed after it. Also, all three functions were wrong AFAIU and AFAIR. Adriano On 28/06/2012 14:02, Paul Vinkenoog wrote: > 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 ------------------------------------------------------------------------------ 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
