minor problem with I18N labels patch

[Kay Sievers]

On Tue, 2005-01-11 at 00:09 +0100, foser wrote:
> On Tue, 2005-01-11 at 10:13 +1300, leon breedt wrote:
> > On Mon, 10 Jan 2005 18:16:32 +0100, foser <foser at gentoo.org> wrote:
> > > the I18N labels patch introduced the problem described in
> > > http://bugs.gentoo.org/show_bug.cgi?id=77140 . Basically when the prim.
> > > & sec. label are the same, the secondary will be only half the size of
> > > the primary & the primary should be used.
> > Right,
> > 
> > This would be because SVD volume labels are UTF-16BE encoded.
> 
> correct
> 
> > Do you have a link to the UTF-16 spec that ensures your strncmp() will
> > never be incorrect due to embedded NUL bytes?
> 
> Incorrect in what way ? There may be a null chars, but strncmp should
> then just return non-zero.
> 
> >  UTF-16 can contain
> > embedded NUL bytes, I'm not sure the way you copy the buffer to pass
> > to strncmp() is safe. I could be wrong though. Perhaps a g_convert()
> > to UTF-8 before doing the comparison is safer, if slower.
> 
> It is safer & cleaner i think, I was under the (wrong) impression I
> couldn't use glib functionality so I came up with my own ad-hoc
> conversion function ;) I'll see what I can do.

Your impression was right, you should not use glib here. :)

This library and it is also used in other projects without glib. We
carry our own conversion function for that reason. We may split that out
and you can use it or you just use set_label_unicode16() with the SVD
value and overwrite it later if the primary is the same string but
longer.

Kay

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal