Re: [devel] Re: [sisyphus] I gtk+-1.2.9

[Sergey Vlasov <vsu@mivlgu.murom.ru>]

On Sun, 11 Mar 2001 20:53:50 +0200
Alexander Bokovoy <ab@avilink.net> wrote:

> On Sun, Mar 11, 2001 at 08:43:18PM +0300, Sergey Vlasov wrote:
> > > Но там еще есть ошибки, так что я --with-native-locale убрал, и
> > > sylpheed-0.4.62cvs4 (из Sisyphus, покореженный на предмет сборки
> старым
> > > rpm) работает, и не падает (им, собственно, и пишу :-). Но опять же
> с
> > > XFree 3.3.6.
> > 
> > Продолжаем исследование. У меня не совсем Sisyphus - glibc пока 2.1.3
> > с Appendix, XFree 3.3.6, но rpm, perl, bash, tar, bzip2, fileutils
> > свежие, так что пакеты из новых src.rpm собираются. Итак, результаты:
> > 1. "Wide characters" для mbstowcs (glibc) и для Xwc* - это не одно и
> > то же! По крайней мере, сейчас в gdb проверил - в 1.2.9-ipd4mdk
> > gdk_draw_text_wc передает в XwcDrawString текст в Unicode (но с родным
> > порядком байтов) - именно так работает glibc (2.1.3). Но на экране
> > рисуется, похоже, младший байт этого значения в кодировке koi8-r. В
> > версии 1.2.8 проблем нет - там все преобразования идут через Xmb/Xwc*,
> а
> > в 1.2.9 при их смешивании получается ерунда. Возможно, это проблема
> > старой glibc (пока не обновил, тем более, говорят, процесс сложный, а
> > описания я не нашел; тащить инсталлятор нет возможности). Или же
> виноват
> > старый Xlib 3.3.6.
> В новой glibc (2.2.2) порядок следования байт в Wide characters зависит
> от ендианности машины, в частности, на PC -- LE.

Так у меня не 2.2.2, а 2.1.3, и тоже LE (по крайней мере в тестовой программке в массиве из wchar_t после mbstowcs() вижу нормальные значения ISO10646/Unicode, а не с переставленными байтами). Видимо, это как раз и есть кодировка "INTERNAL", использующаяся в gconv. А вот iconv при запросе ISO10646 вроде бы должен выдавать BE независимо от машины.

Итак, получается, что wchar_t в glibc - это ISO10646 с родным для машины порядком байт, и в glibc 2.1.3, и в 2.2.2. Тогда возникает вопрос, как рассматривают wchar_t функции Xwc* - тоже как ISO10646 или по-своему? Во всяком случае, у меня на 3.3.6 XwcDrawString получает на вход юникод и рисует вместо него, похоже, просто младший байт. Может быть, в 4.x это исправлено? Завтра придется смотреть на разных машинах и сравнивать.