On 10/05/2010 10:52 AM, Luca Bruno wrote: > Seth, care to comment? > My opinion is that it may be safer to do a plain memcmp, but I suspect the > issue Seth was experiencing was just due to buf_btrfs being not > NUL-terminated. > > The nul termination was in order. The problem is with the GLib::ustring(const char*) constructor not accepting invalid utf8 sequences[1]. Somewhere down the road this leads to a std::basic_string<char>(const char* initializer) call, where initializer is invalid (probably NULL), causing the basic_string::_S_create exception.
So, in effect there should be an analysis: (a) whether there is a constructor to GLib::ustring that won't try to interpret the param as utf8 (treating it as any single-byte char codepage will do, allthough the conversion to unicode is really only overhead here) (b) whether there is a bug in the GLib::ustring constructor making it fail in this manner. Perhaps report upstream. (c) In last instance, not depending on upstream glibmm could be simplest. I think it is not the best tool for the job, especially when treating disk block data. There is no sense in interpreting that as unicode text off-hand, because there really is no telling what the block contains (it could be AES encrypted device, for all we know!). My personal preference would be to discontinue use of ustring where it isn't appropriate (like when comparing binary disk blobs, as in the case of finding filesystem/partition type signatures). But I understand that the impact is high and requires human analysis. So there might be a more efficient solution this time around. [1] This, in it's own right, might make it 'jump' the null-terminator, but that's hardly relevant -- gparted crash at start: glibmm-ERROR ** https://bugs.launchpad.net/bugs/617885 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
