[patch] glib20, UTF-8 and string collation
Alexandre "Sunny" Kovalenko
alex.kovalenko at verizon.net
Wed Jan 9 16:42:34 PST 2008
On Wed, 2008-01-09 at 12:35 -0500, Joe Marcus Clarke wrote:
> On Wed, 2008-01-09 at 10:53 -0500, Alexandre "Sunny" Kovalenko wrote:
> > I have seen recent commit WRT string collation in devel/glib20 by
> > marcus, so I have decided to check if there is an interest to fix SEGV
> > in g_utf8_collate when it is given 8-bit non-UTF-8 string(s) to collate.
>
> Any commits I have made in the area of UTF-8 are completely accidental.
> I am not the UTF-8 guy. Both bland and jylefort have expressed interest
> in this. Perhaps one of them will comment.
I hope so. Just in case, they would decide to, I have reduced the
situation to the small program below. I get
GLib-CRITICAL **: g_convert: assertion `str != NULL' failed
and no core dump from this simple program, whereas Evolution manages to
pass NULL to strcoll further down in g_utf8_collate and get SEGV for its
pains.
Conversely, if the answer still is "Evolution should not have done
that", I will happily crawl back under my rock and keep my patch
locally.
#include <stdio.h>
#include <glib.h>
int main(int argc, char *argv[])
{
GString *str1 = g_string_new("\xf3\xcf\xd2\xcf\xcb\x20\xd7\xcf\xd3\xc5
\xcd\xd8\x20\xcf\xc2\xc5\xda\xd8\xd1\xce\x2e\x2e\x2e");
GString *str2 = g_string_new("Goodbye, cruel world!");
printf("%s\n", str1->str);
if(g_utf8_collate(str1->str, str2->str) == 0)
g_print("%s and %s are equal\n", str1->str, str2->str);
else
g_print("%s and %s are NOT equal\n", str1->str, str2->str);
}
built with
gcc `pkg-config --cflags glib-2.0` -g -o testCollate testCollate.c
`pkg-config --libs glib-2.0`
on
7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Sat Jan 5 22:37:29 EST 2008
using
glib-2.14.5 and libiconv-1.11_1
option "fix string collation" was set during the build of glib.
> I'm not sure why the malloc and copy. Why not just use g_strdup()?
Because I don't know much of anything about glib programming, and I was
suspecting that someone will use g_free() on the result, so g_malloc()
sounded like the plausible candidate. I really hope someone with
the necessary knowledge will come up with the right solution, but, for
now, I do what I can.
--
Alexandre "Sunny" Kovalenko
More information about the freebsd-ports
mailing list