Comment 26 for bug 617885

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