某日記

(中期)

平成15年7月11日(金曜日)

☆朝

．眠いね。

☆ugbabtc

．0.2 を公開した 。 libusb + GNU make 対応して、VineLinux でコンパイルできることを確認。 あとついでに、FreeBSD でもコンパイルできることを確認。 NetBSD / FreeBSD は、デフォルトでは libusb を使わないんだけど、 gmake でコンパイルすれば使うようになる。でもメリットないよ。

☆idnkit

．NetBSD に iconv 入れたんだし、ということで idnkit をコンパイルしてみる。 あっさり動いたつまらん。

．runidn が動いてないような気がするのは、stub が足りてないのかね。 runidn dig してみると EUC-JP がそのまま渡されてるっぽい。

☆iconv

．うーん 、 たぶん n > 0 になってるんでしょうけど、 なんでそれを assert でチェックしてるのか今ひとつ理解できません。

．iconv() の仕様として、 変換できなかった文字があるとその文字数を返すので、 「変換できない文字があったらそれは mutt のバグだ」 とその assertion は主張しているということになると思うのです。 で、「変換できない文字がない」 というのを確かめるには必ず一回変換をしてみないとわからないはずなのです。

．多分 !n を取ってしまって平気なような気もするんですが……。

．このケースで、mutt の作者が意図していると推測できることは、

  1. 一度同じ変換をどこかでやっていて、それが成功することがわかっている
  2. 実はこのコードは逆変換で、「一度ある文字コードに変換した文字列を、 もとの文字コードに逆変換したときには、必ずすべての文字が変換できる」 と仮定している
  3. どんな文字でも UTF-8 には変換できると思っている
のどれかなんじゃないかという気が。 1 は不自然なので 2 か 3 かな、という気が。 2 は必ずしも成りたたないんですけど、今の Citrus iconv では そういう組み合わせはなかったような気がするし、 3 も必ずしも成りたたないんですけど、 機種依存文字でも使ってない限りやっぱり今の Citrus iconv では そういう組み合わせはないと思います。

．もし、機種依存文字が入っているメールを転送しようとして この assertion に引っかかっているのならば、 それは dirty な入力ファイルをエラー処理ではなくて assert で チェックしてしまっている mutt の仕様バグだと思いますですはい。 でももしかしたら、mutt の作者は 「そういうのは入力シーケンスとして invalid だから、 iconv() は -1 と EILSEQ を返すべき」という解釈なのかもしれないので、 ちょっと考えないとだめかもしれません。

．mutt に関しては、 件の pr の件で「いいテストプログラムだよね」と wiz からも言われてるので、 コンパイルして再現環境作ってみますかねぇ。

．なお、「0x1B 0x24 0x42 0x7E 0x7E」という ISO-2022-JP な文字列を UTF-8 に変換したときの挙動の違い： 


Citrus iconv はこの文字を non-identical conversion として扱ってるけど、 Solaris は外字として扱ってて、 GNU iconv は illegal sequence として扱ってる。 SUSv3 的には、 
    If a sequence of input bytes does not form a valid character in the
    specified codeset, conversion shall stop after the previous successfully
    converted character.


なので、EILSEQ にしないといかんのかなぁ。 localdef の charmap と同様のものを導入して、 これを見るようにすればできるんだけど。 別の方法としては、 csmapper レベルで invalid conversion と invalid input を区別するのかな。 












平成15年7月12日(土曜日)




☆iconv





．というわけで、csmapper に手を入れてみた。アップデートするには lib/i18n_module と usr.bin/mkcsmapper を build / install しなおした後に share/i18n/csmapper を build / install 。 libc は、ソースは多少手を入れたものの、 マクロ名を変えただけなので入れ換える必要はないでしょう。 









☆夜





．emacs-21.3 にしてから、default-coding-system を nil にしといても、 日本語のファイルを初回セーブするときに file coding system を 訊いてこなくなってしまったので(勝手に iso-2022-jp にされる)、 悩んだ結果 .emacs に次の行を追加： 
(setq select-safe-coding-system-accept-default-p
      (function (lambda (x) buffer-file-coding-system)))





．LISP / EMACS LISP はさっぱりわからん。 












平成15年7月13日(日曜日)




☆昼





．温泉行くというので車待ち。 


．あまりに暇なので虹裏。 ローレベルフォーマットってなんだよ＞ CANDY TOYS 












平成15年7月15日(火曜日)




☆朝





．すべてにおいてやる気 0 。 









☆which ircd





．ircd 。 同意見多数だと思いますが、 本家本元の irc サーバプログラムと 同じ名前なわけで、いかがなものかと……。 


．長いと呼びにくいし短いとぶつかるし、むずかしいですな 。 












平成15年7月16日(水曜日)




☆朝





．微妙に寝過ごした。 









☆昼





．「GNU libiconv を入れてくれ」と吐く configure.in を書くなよ。 そのうち「Linux を入れてくれ」と吐く configure.in が出てきたらどうしよう。 


．アプリケーションのほうを直せ、と言いたいところではあるのだが、 面倒くさいので alias を足すことにした。 UCS-4 というのはエンコーディングの名前として気持ち悪いんだけど、 ISO-10646-1 というエンコーディング名よりは UCS-4BE の方が 若干まともなのでこいつを alias に足す。 


．夜はこがさんと六本木の聖地に行く予定。今日はフージョンじゃないけど。 









☆CTEXT





．iconv そのものの根本的な問題として、 「UTF-8 → CTEXT の時にどの言語が優先されるべきか問題」 が発生するような気がする。 


．"UTF-8" とか "CTEXT" という名前自体は language neutral であるべきなので、 "UTF-8@ja" とか "CTEXT@ja" とかそういう名前はちょっとダサい気はするが、 まあ iconv のインターフェースでやるのならばそういうことになるとは思う。 でも、今の Citrus iconv の実装で "UTF-8@ja" → "CTEXT" とかされると困るのよね。"UTF-8" → "CTEXT@ja" ならいいんだけど。 この辺は BoF の時に TODO に挙げた気がする。 


．本当は、変換の属性として別の引数として与えられるべきなんだと思うけど、 ただでさえ 2 乗の組み合わせが発生する iconv で、 さらにもう一個自由パラメータが増えるのはちょっとつらい。 












平成15年7月17日(木曜日)




☆昨日





．というわけで これに行ってきた 。 


．この畑の人たちの音楽は、耳あたりの良さとは裏腹に、 音楽的には無茶苦茶高度(というか変態)なので面白い。 演奏という観点では、仙波さんがさりげなくかっこよかったなぁ。 


．んで、その後は焼き鳥屋で晩飯。おととしの小鳥週間に使った店。うまうま。 









☆eucJP-open / eucJP-ms





．昨日の @jp と同じような話はすでに eucJP-open と UCS との 変換ルールで出てきてたりするな。 


．eucJP-open という名前の codeset は、 日本の OpenGroup が EUC-JP を拡張して CP932 との相互変換ができるようにしたものなのだが、 CP932 / eucJP-open と UCS との変換には複数の方法が考えられるので、 Windows3.1 と同じルールを採用する場合には iconv の codeset として eucJP-open のかわりに eucJP-ms を与えよ、というのが この辺 の話。