This is the mail archive of the
mailing list for the glibc project.
Problems with a transliteration module.
- From: John Haxby <jch at scalix dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Tue, 20 Dec 2005 08:57:53 +0000
- Subject: Problems with a transliteration module.
I recently tried to write a gconv transliteration module. I have a
module that probably works, but I'm having trouble persuading glibc to
call it. I'm trying to write a transliteration function that will make
a good effort to produce an ASCII equivalent form of arbitrary unicode
text (although I tend to draw the line at non-latin alphabets).
Anyway, there seems to be two problems in __gconv_translit_find() in
The first problem is that it looks as though the ".so" is appended to
the shared library name after the terminating NUL :-) I can work
around that easily enough with a suitable symlink, but I can't work
around the second problem.
__gconv_translit_find() calls open_translit() and correclty calls
gconv_trans_context() to find the character set names. That's fine.
As, apparently, is the code to store information about the new
transliteration function in search_tree. Alas, it doesn't copy it into
__gconv_translit_find()'s trans parameter so the gconv_trans() function
never gets called and the transliteration doesn't work.
I looked at what looks like the latest snaphot (2005-12-09) and the code
is unchanged. Interestingly, there are two old bug reports for this
same function (in the mailing lists, can't find anything in bugzilla)
that must either arise from code inspection or someone havinjchg a
working transliteration module at some stage.
Is this a known bug? Does anyone apart from me care? Would you be
interested in patch (assuming I get the time)?