蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2009年12月30日分

2009/12/30(Wed)

[OpenBSD] Citrus patch for OpenBSD 4.6-current

@

おまたせ、本家リリースからこんなに遅れたのは初めてかな?
まぁ「ガイア(会社)が俺にもっと輝け(働け)」もそうなんだけど
実はVMWareのディスクイメージを破壊してしまって、リポジトリが消失したのねん orz

んで皆さんに朗報、今から4週間ほど前にOpenBSDではMB_LEN_MAXの定義をMD *1からMI *2に変更したのですが
そのついでにMB_LEN_MAXを1から4(RFC3629でのUTF-8のMB_CUR_MAXにあたる)に増やした模様。
よってこれまでCitrus patchを導入するのを躊躇わせるのに十分かもしれない、patchあてた後の
binary非互換回避のためのuserlandの再構築が不要になりました(説明めんどいのでINSTALLではmake build推奨だけど)

まぁOpenBSDはばんばんlibcのmajorが変わるのでuserlandなんか四六時中rebuildしてる気がするんだけど
binary packagesがそのまま使えるようになるのはうれしいよね(ただしcurrent生活者を除く)

細かいこというとja_JP.ISO2022-JPのようにMB_LEN_MAXが4じゃ足りないlocaleもあるのですが
どうせja_JP.eucJPかja_JP.UTF-8使えれば99.999999%の人の需要は満たせると思うので、MB_LEN_MAX=32化は
別のパッチとして分離します(後日リリースしまふ)、 LANG=ja_JP.ISO2022-JPで生活したい方
citrus.patchをあてたあとでrename.patchをあてて昔通りの作業やってちょ。

ちなみ^1にISO/IEC 2022のような冗長なエスケープを許容するstateful encodingの場合
MB_LEN_MAXは無限大です、この32という値はあくまで 実装上の都合です。

ちなみ^2にわれらが プロジェクトリーダー曰く「 MB_LEN_MAXは42」らしいですぞ。

ちなみ^3にNetBSD-current上のCitrusへの追従はこの一年トドが凍った状態、スマソ。

*1:Machine Dependent - src/sys/arch/*/include/limits.h 参照
*2:Machine Independent - src/sys/sys/limits.h 参照