On 30-06-2012 03:53, Dmitry Yemanov wrote: > 29.06.2012 19:27, Paul Vinkenoog wrote: > >>> - Case for UUID_TO_CHAR will not be changed as this will be backward >>> incompatible. So we live with it, everyone could use LOWER. >> >> Too bad, I would personally have preferred to see it changed. But I realise >> that this could break some existing code. Maybe a convenience function >> UUID_TO_LOCHAR would be nice? > > I'd stay with a need for LOWER, unless other issues would force us to > have UUID_TO_CHAR2 (whatever it is named). >
So the main point here is about current UUID TO/FROM CHAR functions are correct or not in big-endian and what to do if it's not. I think it's wrong, cause it transpose the byte array to a FB_GUID and read USHORTs from it. And considering it's wrong, is Firebird currently stable enough in any big-endian architecture? If it is, we should create the new functions (which will run identical to the current ones in little-endian). If it's not stable in big-endian, then we should just fix the original functions. Adriano ------------------------------------------------------------------------------ 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
