Not only is the Internet dead, it's starting to smell really bad.:2004年07月分

2004/07/03(Sat)

ご無沙汰しています。

@mbrtoc16/c16rtomb/mbrtoc32/c32rtomb

そういえば、Cに新しくchar16_t/char32_tという文字型を追加するという話
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1040.pdf

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1064.pdf
を見ると

Ballot closed, TR is approved and submitted to ITTF, no comments from ITTF yet.

ちゃくちゃくと進んでいるようですね、Unicodeマンセー(棒読み)。
そういやちょっと前のCマガのP.J Plaugerの連載でも話がでてたような。

2004/07/11(Sun)

(ry

@私事ですが

本業もMilestone越えて消火、普通の生活に戻れそうです。
ぼちぼち*BSDいぢりも再開かと。

@嘘を嘘と(ry

メール送っても450 Temporary failureで帰ってきてしまうので、2chで延々マジレス。
http://pc5.2ch.net/test/read.cgi/unix/985675477/196-

196 :itojun :04/07/09 13:50
    citrusをOpenBSD-currentに入れる作業が進行中ですが、__RENAME()がないとかその他いいろな理由で進んでいません。もしcitrus patch(ちゃんとうごくやつ)を隠し持っているひとがいたら是非お送りください。

197 :名無しさん@お腹いっぱい。 :04/07/10 13:32
    神光臨?

198 :190 (1/1) :04/07/11 21:26
    >>196
    どのへんが merge の障害なのか、議論のポインタを知らないので
    役に立つかどうかは判りませんが、↓こちらに置きました。

    http://sigsegv.s25.xrea.com/distfiles/citrus/OpenBSD/HEAD-citrus-20040710.tar.bz2

    最新(2004/07/10) の OpenBSD / NetBSD 両 HEAD branchに同期済です。i386で
    full buildが通ることと、昔のCitrus CVS repositoryにあったtest1, test2で
    NetBSD-currentと結果の相違が無いことを確認してあります。

    NetBSD から mergeしきれていないのは
    1. usr.bin/locale
    stringlist.h が無い、sys/queue.hなり使って書き直す必要あり。
    2. wcsto(u)imax(3)
    (u)intmax_tが無い、inttypes.h とか、c99 回りが整ってからでいいような。
    くらいですかね。

199 :190 (2/3) :04/07/11 21:27
    この tar.bz2 には patch が2つ含まれます。 citrus.patch の方がメインで
    kevlo AT openbsd DOT org 氏 (ttp://www.kevlo.org/citrus/index.html)
    や
    kurati 氏 (ttp://www.nurs.or.jp/~kurari/bsd/index.html)
    が作成されてるモノと(__RENAME()とか__SETLOCALE_SOURCE__の扱い以外)
    あんまり変わらないはず。

    ただ↑だけでは binary compatibility 上
    1. MB_LEN_MAX 1 -> 32
    2. sys_{nerr,errlist} (EILSEQが追加になるので)
    という問題が残りますので、対策として rename.patch を用意してあります。

    rename.patch は NetBSD から __RENAME() を lint(1) への hack 含め、
    一式貰ってくるという乱暴な方法なので、
    OpenBSD 的にはそれはOKなのかちょっと疑問です(だから役に立ちそうもない)。

    そもそもOpenBSD って結構頻繁に libc の major version が上がるのですけど、
    citrus を import したタイミングで bump up できないのでしょうか?
    それなら __RENAME() を持ってきたりする必要はないので、
    citrus.patch を merge するだけで終りという認識なのですが。

200 :190 (3/3) :04/07/11 21:29
    それから、dlopen(3) はあんまり OpenBSD 的に好まれない気がするので、
    locale module を dynamic loading するのでなく、libc に抱え込む
    compile option (CITRUS_BUILD_LOADABLE_MODULE={yes,no}) が
    citrus.patchには含まれています。
    src/libc/citrus/citrus_module_data.h 辺りのファイルが追加になってます。

    もし他に私が見落としている merge への blocker 等ありましたら
    ご指摘下さい。

つか、本物のitojunさんなんでしょうかね(苦藁

2004/07/12(Mon)

@Citrus/OpenBSD

http://pc5.2ch.net/test/read.cgi/unix/985675477/201-
いやはや、ちゃんとテストしないと駄目ですね。
regress/libc/localeをもっと充実させますかぁ。

@multibyte regex?

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/regex/regcomp.c
えっと、UTF-8以外は動かないのかな?

2004/07/13(Tue)

(ry

@FreeBSD rune

FreeBSDではtowctransの内部がliner searchからbinary searchに変更されてた↓ので
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/locale/runetype.c
追従↓してみたんだけど、そもそもusr.bin/mklocaleってorderedでLC_CTYPEを作ってたっけかな。
/distfiles/citrus/NetBSD/05_ctype-cleanup.patch
tjr大丈夫だよね?

UTF-8くらいになると確実にbsearchの方が早いんだけど、
ja_JP.eucJPとか検索量が少ないlocaleは逆に性能落ち気味なので
VARIABLEで切替え可能にする方がいいのかねぇ。

2004/07/17(Sat)

(ry

@en_US.UTF-8.src

FreeBSDと同期。
/distfiles/citrus/NetBSD/06_utf8-fix.patch
サイズは89k。

2004/07/18(Sun)

(ry

@CNS11643-1

http://www.unicode.org/charts/PDF/U2F00.pdf
http://www.cns11643.gov.tw/web/show_seek8.jsp?start=10017&end=10553&stroke=&page=1
を比較するとU+2F23が抜けているのは何故?
そもそも部首についてCNSはUCSへの変換テーブル掲載してないし。

@wctype linear search -> binary search

偏ったデータでなしに、青空文庫からひろってきたテキストを使って測定してみると、
EUC-JPやSJISでも僅かながら性能は向上してますな。
UTF-8だと差は歴然。
singlebyte localeでは_NBRuneLocale->rl_{runetype, maplower, mapupper}が使われるので、
この変更の影響は受けない訳だし、OKかな。

@vfwscanf(3)

vfscanfの%lc(%C)とか%ls(%S)対応をやっててふと
http://www.haun.org/ml/b-l-j/a/100/111.html
「バイト系関数とワイド系関数の混在利用を制限」を思い出したんだけど

char c;
wchar_t wc;

setlocale(LC_CTYPE, "ja_JP.SJIS");
wscanf("%c %C", &c, &wc);

みたいなケースでは、

  %c  →  fgetc(stdin)
  %C  →  fgetwc(stdin)

(あるいは同等の処理)が内部で動くので、formatの書き方ひとつで
「バイト系関数とワイド系関数の混在利用」が発生しそうなんだけど。

上のコードでstdinに { 0x82, 0xA0, 0x82, 0xA2 }というbyte sequenceを喰わすと

  1. c = 0x82, wc = EILSEQ(0xA082)
  2. c = 0x82, wc = 0x82A2

のどっちが正しいんでしょうか。

ちなみにFreeBSDのvfwscanf()は%cであってもfgetwc()が使われるので後者。
漏れは前者が正しいような気がするんだけど。。。

@ungetwc(3)

/diary/?20040118#18-1-1
/diary/?20040123#23-1-1
↑の問題については「混在利用する香具師が悪い」でいいのか。

でもさ、やっぱり戻せないと

FILE *fp;
wchar_t wc;
size_t n;
...
ungetwc(L'あ', fp);
fwscanf(fp, "%C %n", &wc, &n);


というコードで、nはいくつになるか判らんという事態になるのよね。

2004/07/20(Tue)

(ry

@vfscanf

あー勘違いしてるなぁ、俺。
(vf)scanf()の内部で動くのはあくまでfgetc()で、%C(%lc)見つけたら
初期シフト状態でmbrtowc()使って読み込めばいいのね。
http://www.opengroup.org/onlinepubs/007908799/xsh/fscanf.html
のERRORにfgetwc()嫁とあるから誤解してた。
そもそも呼んだらorientation変わってしまうもんな。

逆に(vf)wscanf()は%cを見つけてもfgetwc()で読まねばならないわけね。

@vfwscanf

こっちもモーレツに勘違いしてるなぁ、俺。
%n関して、ungetwc()したワイド文字はバイト数で数える必要なくて1ですね。

2004/07/25(Sun)

@vfscanf(3)

まだろくにテストしてないです。
/distfiles/citrus/NetBSD/07_vfscanf-wchar-support.patch
__sccl()もcollation awareにする必要があるな。

2004/07/27(Tue)

@私事ですが

病院、精密検査を予約。

@tech-userlevel

iconvのprototype問題だけど、SUSv2ではconstありなしが混在していて
http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.h.html
http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html

SUSv3(閲覧には登録要)では
http://www.opengroup.org/onlinepubs/009695399/basedefs/iconv.h.html
http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html
のCHANGE HISTORYにある通り、

The SYNOPSIS has been corrected to align with the <iconv.h> reference page.

として、const無しに統一したという訳ですね。

2004/07/30(Fri)

(ry

@続 vfwscanf(3)

#include <limits.h>
#include <locale.h>
#include <string.h>
#include <wchar.h>
int main(void)
{
        char c[(MB_LEN_MAX * 3)+1], *p;
        wchar_t wc;
        int i;
        mbstate_t st;
        setlocale(LC_CTYPE, "ja_JP.eucJP");
        memset(&c, 0, sizeof(c));
        wscanf(L"%3c %lc", c, &wc);
        for (p = &c[0], i = 0; *p != '\0'; p++, i++)
                printf("c[%d]: 0x%x\n", i, *p & 0xFFU);
        memset(&c, 0, sizeof(c));
        memset(&st, 0, sizeof(st));
        wcrtomb(&c[0], wc, &st);
        printf("wc: %s\n", c);
}

みたいなコード、に"あいうえお"という入力を喰わせると
glibc2/Solaris9/FreeBSD-current全部動作が違いますな...

まずglibc2。
L"%3c"のwidth=3はwchar_t=3の意味で、入力ストリームからは"あいう"が読み込まれる。
引数にはwcrtomb(3)で変換した結果が書き込まれるので、最低でもMB_CUR_MAX * widthのサイズを保証。

c[0]: 0xa4
c[1]: 0xa2
c[2]: 0xa4
c[3]: 0xa4
c[4]: 0xa4
c[5]: 0xa6
wc: え

んでSolaris9。
width=3はchar=3の意味で、入力ストリームからは3byte消費される、
シフト状態は影響を受けない。つまりvfscanfとまったく同じ動きをする。
(MSDNを読む限りVisualC++もこの動作?)

c[0]: 0xa4
c[1]: 0xa2
c[1]: 0xa4
wc: 0xa4

最後にFreeBSD-current。
入力ストリームからはwchar_t単位で読み込まれるが、
width=3はSolarisと同じくchar=3の意味で、
wcrtomb(3)で変換した結果より先頭3byteが引数に書き込まれる。
c[0]: 0xa4
c[1]: 0xa2
c[2]: 0xa4
wc: う
(訂正)
wcrtomb(3)で変換した結果より3byteが引数に書き込まれる。しかしこの例の場合
3byteではshift stateが変換途中なため、ungetwc(3)で書き戻されるので、
結果として2byteのみ引数に書き込まれる(ワケワカラン)。

c[0]: 0xa4
c[1]: 0xa2
wc: い

で、けつねうろんから言うとglibcが正解。
SUSv3にはこうあるし↓

Matches a sequence of wide-characters of the number specified by the field width
(1 if no field width is present in the conversion specification).
If no l (ell) qualifier is present, wide-characters from the input field are converted as if by
repeated calls to the wcrtomb() function, with the conversion state described by an mbstate_t object
initialised to zero before the first wide-character is converted.

それとFreeBSDのvfscanf.cにもいろいろ間違いハッケソ。

@私事ですが

検査前は水すら飲めないのは辛いです。