The Man Who Fell From The Wrong Side Of The Sky:2009年3月4日分

2009/3/4(Wed)

GNU libiconv sucks

おろ、GNU libiconvの//によるswitchを強制的に削るpatchがcommitされてら。
いっそのことCitrus iconvはpluggableな事を生かして、//IGNOREとか見つけたら
GNU libiconvに一切合財delegateするとかどうでしょ(笑)
/usr/lib/i18n/libiconv_GNU_libiconv_sucks.soとか作ってdlopen(3)すると。
まぁ/usr/share/i18n/iconv/iconv.dirにずらーっとsrc/dstの組み合わせ記述すると
確実に氏ねるので、何らかの拡張が必要だけど。

それかいっそのこと//は ストライクスイッチじゃないから移植性に問題ないもん!
と考えて(CES名の一部ってことね)esdb.dirに

UTF-8//IGNORE     GNU/UTF/UTF-8:IGNORE.esdb
UTF-8//TRANSLIT   GNU/UTF/UTF-8:TRANSLIT.esdb

とか追加するとか、やwwwりwwwすwwwぎwww
ただ//TRANSLITはまじでこうする必要がある鴨、/usr/share/i18n以下の容量…

まぁネタは兎も角、おいらの本音としてはGNU libiconvの独自機能に
依存してるのなら迷わずGNU libiconv使ってほしいなり。
前も書いたけどiconv(1) -c相当の機能をiconv(3)から使えない矛盾とか
GNU libiconvのPOSIX非準拠の動作とかいろいろあるけど
そもそもiconv(3)使ったら負けだと思ってるので、どうせ負けなら
GNU libiconvを正しくリンクして盛大に負けた方が誰もが幸せ。

[NetBSD] __link_set_* + static link

current-user、setlocale.cの_find_category()が期待通りに動いてなさげ。
要するに-staticの場合、各locale categoryの*.oがlinkされないので__link_set_declの中がdummy以外は空状態。
まぁそういうもんだと納得なのだが、これopenpamの-DOPENPAM_STATICでは何故問題になってないんでそ。
DragonFlyBSDもopenpamをインスパイヤして、citrus_module.hをNetBSDのものから拡張して
__link_set相当を使ってstatic linkedの場合でもmultibyte locale使えるようにしてたとオモタのだが…

さてどうやって直すべ。

かなり負け犬っぽい patch
もうこれlink_set使う意味ないお…

今日

某党首「(OSは)私は全てオープン(BSD)にしている」 なるほど、鉄壁の守備ですね。

2次補正予算成立をうけて少子化対策担当大臣、「景気てこ入れに消費刺激策」の次は
「出生率てこ入れに 下半身刺激策」、自〇対策担当大臣と兼任以下略
すいません最近かなり暗黒面に落ちてますです。

新MacMiniちょろっとしか使わんだろうで下位機種でいいのだがそれでも高いな。
それにDVIなディスプレイを持ってない(つかまだブラウン管使ってる)俺脂肪。

なんかSEDも有機ELも SSTみたいな永遠の次世代になりそうなので
そろそろ液晶に移行すべきかも。

某家電量販店の店頭にあるのを見た限りでは、写真やるなら NEC MultiSync LCD2490WUxi
sRGBのわりに他より頭一つ飛び抜けて色がまともな感があったのだけど予算が…
ちゅうかAdobeRGBな2690と値段大して変わらないのな。

とりあえずjoerg氏への返事を書いたのと、current-userの件にpatchを送った。
んでiconv(3)はどうしましょかねぇ…

[NetBSD] New I18N API?

joerg氏からお返事、要はThread Aware Locale Extensionみたいなダサいものではなくて
もっと洗練されたオレオレAPIを作りたいらしい。
俺も正直TALEは嫌なんだけどねあんなダサいの。locale_tとmbstate_tを別管理とかマジ死ねる。

でもおいらはlibstdc++のmulti-locale実装がglibc用のコードを手直しせずに動くようになって
なおかつglibc2やMacOS Xとのソース互換ウマウマーってレベルで十分幸せだと思うんだけどねぇ。

誰が見ても非の付け所のないちょーカコイイNew I18N APIを設計したとしても
NetBSDローカルじゃなんもうれしくないのですよ、やるならlibcと切り離して
単体で配布できるようにするか、libcに置くなら標準規格になるまでとことんやらんと意味なし。
kernelの話ならいくらでもオレオレAPI作くりゃいいと思うけど
移植性の無いI18N APIなんてチラシの裏より役に立たんわけでして。

少なくともglibc2はFree Standard FoundationにてLinux Standard Baseちゅう標準化をして
更にそれをAustion GroupとかJTC1/SC22/WG14にフィードバックかけたり、Technical Report作って
C1Xに入れよと努力してるからね、それと同じ努力をNetBSD/Citrusの所帯ができるかっつーとまず不可能だお。

実装面でも、今Citrusはmb/wc変換(ctype)とiconv(stdenc,iconv,mapper)は
お互い依存しないように作ってあるので、mbrtowc_enc()みたいなのは
Citrusより上でやれって話になるやね、libc置くよりはlibutilあたりが妥当。

ただし地獄の業火で焼かれるべきC++0xのchar16_t/char32_tがらみの話もあって
c16rtomb/mbrtoc16/c32rtomb/mbrtoc32なんてウンコを実装しなけりゃならん可能性もあるので
そうすっとcitrus_ctypeでもcitrus_mapperをrequireする必要がでてくるのよな。
この見直しをするとCitrusレベルでmbrtowc_enc()みたいなのを実装できる余地はある鴨。

頭痛くなってきた。

本気でやるなら CERT managed Stringのstring_mのように
文字コード情報埋め込みの文字列型を用意するべき。
ただしCでそれやると余裕で氏ねるのが難点。