The Man Who Fell From The Wrong Side Of The Sky:2008年11月分

2008/11/1(Sat)

Writing Insecure C

kbkさんとこ。
流し読みした程度ですけど、それなりに参考になる記事だと思うんですがねぇ。
記事をクサしてるespie氏はOpenBSD developerですので
OpenBSDの名前出すならtheo様のお言葉を一言一句正しく伝えろゴゴゴゴ、というノリかと(ぉ

まぁ包丁禁止レベルでマクロ完全否定 *1せんでもとか
非OpenBSD環境にも優しい記事の必要性考えろと思うアテクシ。

memory handlingがうんちゃらゆーとるのは昨日書いたalloca(3)の戻り値の件かね。
それともSolarisのmalloc(3)のmanにはこわい!事が書いてあったりする件?

WARNING
        Undefined results will occur if the size requested for a
        block of memory exceeds the maximum size of a process's
        heap, which may be obtained with getrlimit(2).

ヒャッハーmallocの戻り値がNULLかどうかチェックしたところでお前ら無駄だぜ、ヒープ溢れたら未定義動作だ!
ってこれ規格違反だとおもうんですが(allocaの場合はそもそも規格ないから)
だからWARNINGセクションか。

それともmalloc(3)全否定、常にcalloc(3)ちゅー話?
そいやOpenBSDって最近recalloc(3) 消しよったよなーhehe

ってあれだ、記事読み返したらPart2-2 Memory Woesあたりの参照カウンタの話っぽいの。
GNUstepとか知らんのでなんともいえん。

pointer -> integer変換については「JUST DON'T DO IT」で終わりちゅうのもどうかと。
そんなら「ピーはコード書くな」ちゅう極論でおk。

*1:そいやCitrusがOpenBSDにmergeされなかった(過去形)のは、dlopen(3)嫌い以外にも
マクロをテンプレートエンジン代わりに使いまくっとるコードのせいのような気がしてきた。

2008/11/2(Sun)

今日

連休、日光に写真撮りに行きたかったが今年は体調がヤヴァイのでおとなしく。
H2ブロッカー胃腸薬の大量投入で出血は止まった模様。

ThinkPad X61のセットアップをようやくはじめた(買ったの2月)。
VMware Server2(free)がどーにも落ちてこないので1.0.7で我慢の子。
メモリ1Gだとclientに512MBも割り当てるとスラッシングで使い物にならんの。

CPU使用率:8% 物理メモリ:94%

2kならこれでも問題ないのにな、Vistaビザすぐる。

OpenBSD 4.4でたのか、 いつものやつ作らんとな、誰も使ってないだろうけど。
まぁNetBSDの作業優先なんだけどね。

[NetBSD] new locale db for 5.0

このへんの話の続き。

とってもevilなんだけど、iconv(3)使わずともlocale.aliasで

af_ZA.ISO8859-15/LC_NUMERIC	af_ZA.ISO8859-1
...
ja_JP.ISO2022-JP2/LC_NUMERIC	ja_JP.ISO2022-JP
zh_CN.GB18030/LC_NUMERIC	zh_CN.eucCN

ちゅー感じでISO8859-1/ISO8859-15あたりはaliasにしても動くよな *1

ただしLC_MONETARYだけはISO8859-{1,15}の場合、currency_symbolのユーロ記号(0xA5)が互換性ないのでダメ。
af_ZA(ザンビア)とen_GB(イギリス)のように通貨がユーロじゃないとこはOKだけど。

そいとen_US.US-ASCII追加すれば、en_US.ISO8859-{1,15}とen_US.UTF-8はそいつのaliasにできる。
というか、なんでen_US.US-ASCII無かったんだ :D

iconv(3)を使うとした場合、en_US.ISO8859-1@ucs4のようなlocale name modifierの実装もあわせて考えないと
ゴチャゴチャになりそう、正直5.0へは時間が足りなさげ。
ただしこれを実装しないと*.UTF-8の定義ファイルを全部メンテせんとならん。

*1:むしろiconv(3)噛ますと遅くなる。

2008/11/3(Mon)

[NetBSD] libc major crunk

うーん何でlibc major crunk用の枝切らないんだろ。
christos_time_t枝はそっからの枝分かれという形にしないと、time_tの変更をmergeするだけで
HEADのlibcのmajorをあげなきゃならんので、他のABI失う変更をこの1回きりのbumpでつっこめなくなるぞ。

こりゃ早めに6.0でのlibc major crunkに合わせて、ctype tableの32bit化と
wchar_tのunsigned int化「も」やる宣言しとかないと、OpenBSDよろしく何度も
major bump繰り返す羽目になるよなー、まぁ俺はそっちで慣れてるからいいけど(ぉ

今日

ThinkPad X61のメモリを2Gばかし増設、サクサク動くようになった。

おーしってんでWindowsUpdateかけてVista最新にしたら
次回のVMware guest起動時に

CPU使用率 87%
物理メモリ: 99%

でハングしたまま応答がなくなりよる、投意沸いてきたマダファッカ。

ググルと こういうことらしい。
10 minutes lockupって銀行の窓口でも出直すわ。

めげた、こうしてまた貴重な連休が無駄に潰れましたが何か。

2008/11/4(Tue)

今日

VMware ServerがVistaで「10分固まるのだぞ」「ちゃん!」問題は
Disable memory page trimmingにチェック入れたら回避できた。

浅倉大○先生がなりきってお縄頂戴するシーンを想像して午後の紅茶噴いた。
「TETSUなりきり講座」か…元KB SPECIAL読者です。

ミーハー雑誌と見せかけて、寿博士(a.k.a 岸野雄一)「京浜兄弟社 presents テクノ恩返し」
クラウト・ロック特集とかグラム・ロック特集やっとったから何気に侮れんのよね *1
90's入ると例のバンドブームで一気に質が下がったので読まんようになったけど。

以下、 樺太ワークの名曲をお届けします、蟹を捕まえるだけの簡単なお仕事です。

ファンファンファン、 道路公団

ボクハセイジカ、 ソロバンカタテニ
タシタリ、ヒイタリ、ヨロンソウサシテ、ムリョウカスル
ザイゲンムシシテ、マニフェストカナデル

人気無いからキャッシュバックキャンペーン(=定額給付金)ってWindowsVistaみたいな政府だな。
しかもサイゼリア返金方式とか意味がわからん、こっちもオワットル。

*1:他にもTodd Rundgren, Frank Zappa, Captain Beefheart, the Residents, Brian Enoあたりも特集してたな。

2008/11/5(Wed)

今日

Vistaがいつ終わるとも知れぬ謎のディスクアクセスをしてくれやがるお陰で
バッテリの消耗速度が異常に速い、マダファッカ。

Disable memory page trimmingにチェックを入れても10分間ロッキング再発しよった。
嫌になって1.0.7 -> 2.0.0にアップグレードを凶行。

権限やら証明書やらファイアーウォールやらプラグインやらの問題で
うまく動かん、つかなんでわざわざVMware ConsoleをWeb Service化する必要が。

いい加減痺れを切らしてThinkPad s30のインバータを某所でポチるというデッドエンド。

刺身にタンポポsrc/share/locale/* をお掃除する仕事をはじめたお。

とつか再開発くんの次は これか、また東戸塚と保土ヶ谷にバカにされる…

著作権について不勉強なので 「日本は未熟だ」テンプレ使いました、テヘ。
楽曲使用権とはまた別の独立した権利である出版権+原盤権(いわゆる隣接権)の話をくそみそに
すべて著作権ひとくくりなので、何をどう偽ったのかさっぱり読み取れん記事その1。
未熟なのはマスコミか。

2008/11/6(Thu)

[NetBSD] new locale db for 5.0

引き続きsrc/share/locale/*のお掃除中、遅々として進みません><

am_ET.UTF-8(Amharic - Ethiopia)とかhe_IL.UTF-8(Hebrew - Israel)みたいな
dense encodingがなくていきなりUTF-8というものは困ったもんだな。

まぁヘブライ語はISO8859-8でもCP1255でもお好きなものを追加すりゃいいんだが
アムハラ語=ゲエズ文字とかいわれてもよくわからん、困った。
ftp.ethiopic.orgでfontその他ひととおり揃う模様、そのうち勉強する。

そもそもエチオピアといわれても Radio Ethiopiaby the Patti Smith Groupくらいしか思いウカバナス。

ガッシボッカ、キリストは他の誰かの罪で死んだ
でもそれは私の罪じゃない、スイーツ(笑)
パンクじゃないのではずかしくないもん!

	- 「グロリア」 パティ・スミス

After Unicodeの福音(注:イヤミです)で、今の時代わざわざdense encodingなんぞ用意しないからな。
Before Unicodeの時代のように、自らl10nする作業を経ないと こういう感情のもつれが起きるのだけど *1

我が身を振り返ると、ja_JP*含めて、言語/文字/文化についてしょせん
ググった情報程度の理解しかないおいらレベルがCitrus(=NetBSD)のlocale dataの
メンテ作業をしてるっちゅーのもとっても危険な話なんだよな。
相手の文化を誤解するちゅーことは昔っから争いの種であることを考えるとね。

時々自分がランボーのように間違った戦場にいるような気にもなってくるな。
まぁ[お察しください]みたいにノーチェックで おれ一人で現地語化157個を始末したぜ!
ちゅうことはしてないつもりだけど。

そいや先日ネタにした「今度は戦争だ」ってコピーは、ランボー2じゃなくてエイリアン2だったな。
これも文化を誤解(以下略

銀塩趣味の方で使おうかと思ってたソフト、 Vuescanなんだけど
日本語メッセージカタログがtranslate.google.comを通しただけなので
Profileが横顔とか訳されてたり、トーフ化けしたりしてるせいで使いものにならん件。
こういうのが怖いのよね。

間違った場所といえば、げー the Wrong Side of the Sky / Gavin Lyall も廃版なのだな。
航空小説はダールより初期ライアルだろが…ハヤカワ…

今日もあいかわらずgdgdですな。

*1:まぁ経てもモメるがw

昨日

SONY α900おさわりしてきた、視野率100% 倍率0.74のファインダーマジパねぇっす。
つか某家電量販店、店頭品にCarl Zeiss Planar T* 85mm F1.4 ZAをつける反則技に噴いた。

まぁおいらにはMinolta X-700の視野率95% 倍率0.9とMC ROKKOR 85mm/F1.7 があるので買わない(買えない)けどな。
つまりはミノとその血を継ぐものはファインダーが神いわゆるゴッドちゅうわけです。

α900 + MC ROKKOR 58mm/F1.2(αマウント改造)
αマウント化してリイシューしないかねぇ、このレンズは新旧で2本持ってるけど改造したくないしな。
58mmというレトロな画角は、APS-Cにつけると換算85mmになるので
(50mmの換算75mmだとちょっと使いづらい)今の時代もっと見直されてもいいはず。

最近ここの家電量販店経由でモノクロ現像出すと瑕だらけで帰ってくるのだよなぁ。
どこと契約してるのかしらんけど、モノクロはスキャン時にDigital ICE利かないので致命的なんだな。

2008/11/7(Fri)

今日

渡辺美里 + The Who が西武球場で サマータイムブルースを熱演し、更に
新曲 (talkin' about) マイレボリューションを披露する予定も、今回のTK逮捕で急遽中止に。
ウソです(AA略

The Who風(モッズマーク風)信玄餅をうちの若いのから教えてもらた。

最近 Gerard de Thameの映像がお気に入り。
Wonderful Lifeとか、おっちゃん懐かし過ぎて目から変な汁でてくらぁな。

Cathedral Song みてモノクロポジやりたくなってきた(映像は大判8x10のカラーポジだろうけど)。

まぁそんな道楽はじめよったら、確実に Rolleiへのお布施で破産できるので
入手がわりと容易なフジのミニコピーHR IIのクリアベースモノクロネガで遊ぶくらいかな。
あれ使うの難しそうだけど。

巷で噂の 超高級LANケーブル、まぁそれはどうでもいいのだが
ノイトリックってLAN端子も作ってたのか、知らんかった。

昔PA屋のバイトやってた頃、丁度XLRやフォンジャックから スピコンに切り替わる時期だったのだけど
当時いたスタジオがYAMAHA 4115を WAVEFORCE(not サウンドボード) にリプレースした時
なんじゃこの端子は!!と驚いたオッサンです、あれいろいろ便利で感動したな。

んで当時一緒に入替えたミキサーがYAMAHA M2000。
TK先生がフランスW杯のエッフェル塔で自己陶酔しながら操作(というか演奏w)してたアレ。
あれはテレビで見て噴いた、絶頂期だったな。

2008/11/9(Sun)

今日

しかし天気悪いな。

押入の天袋からねこがひょっこり帰ってくる夢を見て凹んだ。
ドラえもんなら帰ってくるんだがなぁ。

今日はリッチに蟹炒飯作った、K&Rじゃないよ!
缶詰のパッカンという音がしようもんならダッシュしてきたんだけどな。
さびしい。

VMware Server2 + Windows Vistaまとめ。

もう疲れた。

2008/11/10(Mon)

[NetBSD] new locale db for 5.0

ThinkPad s30復活、ぁぁぁぁぁぁまたこんなジャンクを延命させてしまった…

とりあえず手元の環境のlibcをnew locale dbを使うようにコードをmergeしてみた。
もうちょい細かいところ修正したらpatchとして放流してチャレンジャー募集予定。

つかCITRUS=noの場合、ctypeio.[ch]を使うコードの存在を忘れとったのでそこを書かねば。

めんどくさいので厳密なABIは保つのは止め。
libc内部実装だけで使うコードで不要になったものはsim書かないことにした。
まぁ度々やってることなので問題無いはず。

citrus_*をsrc/lib/libc/cirusにぶち込むと、Makefileの関係上objectのlink順を保証できかねそうだったので
__link_set_entry()によるby indexでなく__link_set_foreach()によるby category-idに改めた。

しかしpullupめんどくさいな、WAPBLあたりが不安定になって、4.0の時みたいに枝切り直しになれ!(ぉ

んでこれ終わったら6.0向けの32bit ctype table他の作業か、俺この作業終わったら紅葉撮りに行くんだ *1

*1:手遅れです。

昨日

ネピア鼻セレブ のペンギンのヒナの写真が暴力的にかわいいのだがググッてもヒットしない。
この写真もいいな。

2008/11/11(Tue)

[NetBSD] new locale db for 5.0

Solaris8にて

$ LC_MONETARY=ja_JP.eucJP locale -k currency_symbol
currency_symbol="\\"

へー。

localeconv(3)だと

$ cat >test.c
#include <locale.h>
int
main(void)
{
	setlocale(LC_MONETARY, "ja_JP.eucJP");
	printf("%s\n", localeconv()->currency_symbol);
}
^D
$ make test
$ ./test
\

なので、エスケープはlocale(1)がやってる模様。
どうすっかな、shell scriptなんかでcurrency_symbol使うならこの方がいいのだろうか。

ja_JP.eucJPでもcurrency_symbolが0x5Cになるので、XFree86/xorgのフォント関係
全部グリフをREVERSE SOLIDUS -> YEN SIGNに変更したら投されるかな *1
XSunのフォントって確かREVERSE SOLIDUSだったよな。

それとja_JP.eucJPのLC_TIMEの定義はひでぇなこりゃ。
UI-OSF日本語実装規約どおりに直さないとなぁ、こりゃ他のlocaleが思いやられるわ。
やっぱりFreeBSDから持ってきたの一言で妖怪レーダーピコーンだな、特にlocale周りはまるで駄目お。
これ昔open-std.orgで配布してたlocaledef srcを使ってチェックするしかないか…トホホ。
だからこの辺localedef(1)の実装が終わるまで触りたくなかったんだ、ブツブツ。

ちゅうか%Dとかstrftime(3)がどういう実装してたか調べないと、場合によっては
LC_TIMEにわっさりフィールド追加せんとあかんわこりゃ。
きっと[お察しください]はstrftime(3)の仕様読んでないに違いねぇ。

それとdate(1)の中でstrftime(3)渡すフォーマットが

120
121         format = "%a %b %e %H:%M:%S %Z %Y";
122

あちゃー、これはダメでそ。

d_t_fmtフィールドだと曜日及び *2タイムゾーンは含まない && 出現位置はロケールによるので
これ結局strftime(3)でいうとこの%+用のフィールドを新規に追加しないとならんちゅうこと。

げーそれ5.0までとか絶対無理、6.0以降だな。
どっちみちERAとかの問題もあるし。

それまで皆様

$ LANG=ja_JP.eucJP date
月 11 10 01:04:23 JST 2008

というオマヌケな表示で我慢してもらおうか。

でも、きっと俺のせいにされるなー
no no no no-no-no---body's fault! アァァアァァアーアー

*1:やりません。
*2:なぜかSolaris8はd_t_fmtに曜日含んでるな、なんぞこれ。

昨日

ミニキーボード差し入れ、相変わらず Idiot Boxぶり健在でんな。
これとかだと嬉しいかもね、つか YAMAHA KX-5 Tetsu Mind Controlだったら嫌だ。
裏社会にマインドコントロー(ry まぁ事実関係は裁判を注視で。

おいらの場合は これ*1を差し入れてくれると嬉しいです。
小学生の頃、これとラジカセ + OLYMPUS PearlCorderで多重録音やってた。
ゆで玉子切りにピックアップつけてギターにならないか研究したり、カセットでループ作ったり懐かしい。
さぁ リリコンのつもりで縦笛を全力でブロウするんだ。

こういうことを書いてると、明日会社帰りに これと赤いシャツ買ってしまいそうで怖い。

リア厨時代、クラスにTM Network大好きなX68000使いがおったのだけど
4オペFM音源 + 4ビット? PCM音源だかで必死にゲゲゲゲッワーイ(ワーイ)やっとったので
とりあえずKeyboard MagazineやKB Special誌なんか貸して、シンセオタ道に洗脳してみたら
当時彼鍵盤弾けなかったにも関わらず、遂にはYAMAHA X'ART SYSTEMを組むに至るまで暴走したもんだ。
YAMAHAもいくら大阪=Rolandといっても、収監中はそっち足向けて寝られんはず。

さらに後日談、それからむにゃむにゃ年後、そのツレはX68000使いの常としてデバドラ屋に。
んで当時おいらは全くパソコン使えなかったのだけど、就職したしウインドーズにエクセルワード覚えたい
と軽い気持ちで相談したら、な…何故か…ThinkPadとFreeBSDのインストール本…はーい痛くないから(以下略

要するにTKおらんかったら俺はNetBSDデベにはなってなかったという、いやー報復洗脳って怖いね!

*1:高野寛もこれ使ってたんだっけか。

2008/11/12(Wed)

[NetBSD] GNU gettext

あるえ?最近のGNU gettextのshlib version bumpってgettext-toolのlibgettextpo.soの変更が元で
libintlに影響あるようなABI変更なかった記憶なんだが(汗
printf(3) positional orderもchristos氏がFreeBSDから持ってきて終わってるはず。
何が足りないのだろう、つかpullupしろってこと?

[NetBSD] 続 GNU gettext

塩崎さんとこ読んで ググるしてみたら msgctxtはこーゆーことみたいですね。
ということでlibintlのminor bumpとsrc/gnu/dist/gettext合わせて対応が必要かと。

よろしくお願いします(ぉ
src/gnu/dist/gettextは前回christos氏がやったんだっけか。

[NetBSD] new locale db for 5.0

作業中の 差分 for 5.0 tag、とりまlibcにmergeしてふつーに動いてる模様。
src/share以下はまだ作業終わってないのでlocale db自体は手動でどぞ。

TODOは相変わらずで

など。

今日

ウェル ウェル ウェル しょうがねぇデボーチカだな。
お前、ミルク・プラスって言いたいだけちゃうんかと。
コロバ通の俺から言わせてもらえば、今ナッドサットの間での最新流行は
やっぱりミルク割りベロセット、これだね。
グロムキーなモロコにベロセットとシンセメスク。これが通の頼み方。
しかしこれを頼むと次からミリセントにトルチョックされるという危険も伴う
諸刃の…あれ、雨も降ってるのに呼び鈴の音が。

2008/11/13(Thu)

[NetBSD] new locale db for 5.0

FreeBSD由来のlocale定義ファイルでは未だにsr_YU(ユーゴスラビア)なのな、オワットル。
せめてOpenSolaris並にsr_CS(セルビアモンテネグロ)だろJK。

既にモンテネグロもUNが独立承認しとるので、sr_ME(モンテネグロ)とsr_RS(セルビア)に分割だな。
しかもsr_YU.ISO8859-2とsr_YU.ISO8859-5でLC_NUMERICの定義が一致してないという、どんだけ。

glibc2の出力をみてると、sr_MEとsr_RSで同じsr(セルビア語)にもかかわらず
LC_TIMEのabdayなんかの定義が若干違うようだ、なんぞこれ。

セルビア語とクロアチア語はほぼ同じ言語が独立したから別言語、みたいな扱いになってるけど
それと同じようにセルビア語とモンテネグロ語みたいなことになってんのかね?

欧州情勢は複雑怪奇。

VMware Server 2.0.0

先日 あまりのめんどくささに泣いたIEやFirefoxによるログイン以外に
別途VMware Infastructure Clientがサポートされててそっちの方が楽ちゅうことが判明。
デフォルトではインスコされないので

${InstallRoot}\VMware\VMware Server\hostd\docroot\client\VMware-viclient.exe

という名前のインストーラを100万回叩けばOK。

IPアドレス/名前に「マシン名:8333」入力、オレオレ証明書の警告は出るもののさっくりログインできた。
これでtomcat6は止めてしまっても全く問題なさげ、いえー。
ちゅうかserver.xmlにport 8333のコネクタが存在しない理由はそれかwww
uiだけがServletの方にredirectされてるちゅうことか、SOAPだかXML-RPCは本体がやってんだな。

んで 以前書いた xvmwareも特に問題なく動いてるもより。
いやまぁ謹製のopen-vm-tools使えばいいんだけど、あれって見た目オンリーでgtk+2要求したり
意味もなくdaemonとしてバックグラウンド動作させてるのでsetres{u,g}idしたりと
どうにも好きになれんコードなんだよな。

2008/11/14(Fri)

[NetBSD] new locale db for 5.0

うーむ、locale(1)のコードでPATH_LOCALEを取得するのに

402:        /* get actual locales directory name */
403:        setlocale(LC_CTYPE, "C");
404:        if (_PathLocale == NULL)
405:                errx(1, "unable to find locales storage");

と直接libcのシンボル参照しとるのか。

new locale dbでは、C localeの場合どーせlibc組込だし不要っちゅうことで
_PathLocaleを確認しないのでNULLのままなんだが、それが仇となって
バイナリ互換が失われちまっとる、新しいlibcと古いlocale(1)の組み合わせで
正常に動かんようになっちまうな。

そもそも新しいコードではインストーラーなどの組込libc向けに、非C localeでも
ファイルからlocale dbを読み込まない(=_PathLocaleとか必要ない)実装と差替るのもアリ
ということでsetlocale(3)から_PathLocaleの分離を図ったんだが、元に戻さないと駄目やね。
しょぼーん。

あと今citrus_lc_*.hにづらづらdefineしてあるlocale dbのkeyだけど
locale(1) -k用のkeywordとUnifyした方がよさげ、緊急性はゼロなのでそのうちね。
というかこのkeyword listの方、こっちはlibcが持ってる方がいいのだろうな。
sysctl(8)がoptions SYSCTL_INCLUDE_DESCRでkernelに持ってるようにね。

あとmklocale(1)はtoolchainなので-DHOSTPROGなどを追加。
んでlibutilのefun(3)も使えないのでLDADD=-lutil他を削除。
これで./build.sh tools が通るようになったはず。

んでLC_MESSAGESだけLC_MESSAGES/SYS_LC_MESSAGESとglibc2風にsubdir化。
以前のアイデアだとSolaris風に

 /usr/share/locale/ja_JP.eucJP/LC_TIME/localedb.1
 /usr/share/locale/ja_JP.eucJP/LC_TIME/localedb.2

みたいにsubdir化して、db自体にもversion suffixを付与しようと思ってたのだけど
現状LC_CTYPEはそうなってないので、これは取り込んでいない。
どうしよーかなー、LC_CTYPEもsubdir化する方法があればやるんだが。

それにしてもいい加減distrib/sets/*でcheckflistするのは頭悪すぎる。
しかもsyspkgがsuspendしてる現状でもそれ用の項目書くのもかったる杉。
この手のfileはMakefileから自動生成するべきだよな。

あとstrtol()使っちゃダメよについいては、citrus_module.cとかcitrus_euc.cにも同件のバグがある。
うーんcitrus_bcs.cに_bcs_strtol()を用意するかねぇ。

citrus_bcs.[ch]は将来的にmulti-locale化すれば不要になる予定だし
ここでリッチにする旨みがないのよな。

つーわけで最新版の patch、今度はlocale dbもインスコします(UTF-8以外)。

んでja_JP.ISO2022-JPロケールの名称をXFree86/xorgに合わせてja_JP.ISO-2022-JP変更。
一応こないだlocale.aliasに 追加してたんだけど、本格的に直した。

今日

最近Subversionがバージョン上がる毎にウンコになるので
コード書くときにすっかりSCM使わなくなってしまった。

彼氏がSubversion使ってる、別れたい。

彼女をCVS(以下略、なんてスレあったなそういや。

匠の技

s/中古/ビンテージ/

まあ、なんということでしょう!

SCMとかLLって流行服みたいなもんだよな。
いろんな服に詳しくなくちゃならないとか、とにかく新しいものがお洒落ちゅう風潮を感じる。
まぁどうでもいい。

明日はコード書くのに飽きてるので、脱走して北へ向かう予定。

2008/11/15(Sat)

今日

グリーン車で酒盛りして馬鹿騒ぎする50〜60代のオッサンオバハン集団やら
ニンニク臭振り撒くクチャラーなどに次々と襲撃を受け、チルアウトどころか
デストロイな気分で帰ってきた。

お土産で買ってきたかまぼこもこれ不味なり。

Writing Insecure C

lukewarmさんとこの Writing Insecure C Part2 日本語訳
原文読んだときは気づかなかったけどFreeBSD reallocf(3)推奨はちと嫌ですな。
移植性ない上に、エラー時に勝手にfreeするから別のとこでpointer参照してたりすると
double freeしかねない諸刃の剣かも。つかこれ元々

[誤った使い方]
char *s;
size_t newsize;

s = realloc(s, newsize);
if (s == NULL)
    return ENOMEM;

[正しい使い方]
char *s, *t;
size_t newsize;

t = realloc(s, newsize);
if (t == NULL) {
    free(s);
    return ENOMEM;
}
s = t;

と間違ったreallocの使い方されるケースが非常に多く、reallocに失敗した時に
メモリリークが発生しまくるコードが大量にあったちゅう背景があって
それを回避する為にFreeBSD方面が発明したkludgeなのですよね。
reallocに失敗した場合はabortしちまうのが一番安全だし、どうせabortするなら
freeする必要も無いわけですし *1

ちゅうことでここは正しいreallocの使い方を説明するのが先決だと思われ>>元記事。
つかPart 1で↑のよにmalloc失敗したらabortという原則を出してるのだから、ここは
NetBSDのefun(3)にあるereallocのようなものを推奨すべきでしょう、矛盾しとる。

それとmallocに対するallocaのようにasprintfにもスタック版が欲しいと書いてるけど
Part3でallocaによるstack overflowの危険性を説いてるんだからこれも矛盾ですやね。

あとespie氏もundeadlyで指摘してたrefcountネタは確かにいけてないなぁ。
malloc/freeくらい簡単なものをまともに扱えないのに、更に複雑なものを使わせるのは
この辺の話と一緒で、余計物事悪化させますやね。

*1:malloc/free論争する気はありませぬw

2008/11/16(Sun)

[NetBSD] source-changes

Nobody tested this?ってcommitしたの 自分なんだからブーメランでんがな。

つか実装の方もFreeBSDのアレなprintf/scanfを検証せずにパチってきたせいで
いろいろ問題発生してるわけで、 これこれ、そして このデグレとか。
こっちも直すタイミングはmulti-localeでと考えてるので
指摘するとうるさそうなので放置してるけど。

scanf positional orderの方も途中まで書いてはあるんだけどね。
もともとformat string parserをprintf/scanfである程度テンプレ化する思想だったので。
ただしsinglebyte locale / multibyte locale用で実装を切り替える仕組みを導入して
性能を確保せんとならんのよな。

NetBSDの場合はTheo様のように「速いマシン買え」とかいうのは
既にディスコンなarchが多いのでご法度やね、ネットキ慈愛の拳。
どうみてもOpenBSD=ラオウの方が相応しいです、つかTheo番長「知ったことかー!!!」

昨日

かわいいカメラに首ったけ!』(エイ出版社, 2008年11月)に Minolta Hi-Matic Fに関するガセーネタが載っていた *1

Apollo計画で月に持ち込まれたカメラとして紹介されてるが
実際に使われたMinolta製品はHi-Matic Fではなく 露出計の方でんがな。

そもそもHi-Matic Fが発売されたのは 1972年6月、アポロ計画は最後の17号(同12月)を残すのみって時期だし。

Mercury計画ではFriendship7(Glenn)が Ansco Autoset( Hi-Matic無印のOEM製品)を
使用したのだけど、それとの混同だろね。
#別ページには正しい記述もあるのでチェック漏れかな。

ちなみにAnsco Autosetが宇宙を飛んだのはこれ1度っきり。
次のAurora7(Carpenter)は Robot Recorderを使用、Sigma7(Schirra)以降は HasselBradを使うようになった。
これにもある通り実際に月面で使用されたカメラはHasselblad EDCでんな。

次にMinoltaのカメラが宇宙を飛ぶのは「これ本番ですか?」秋山記者の α8700i
これを8年落ちくらいの中古で買って以来、αマウント奴隷な私。

*1:オマージュしてみた(謎

2008/11/17(Mon)

昨日

塩辛もイマイチだった。

ボクハ シオカラツマミニ バンシャク ハハ
ヨッテル イッショウビン モドストキ

やぱし先日の呪いが効いたのかWAPBLが超不安定、5.99.02。
おかげでおそらくkern/39924と同件でVMware上に作った環境がシボンヌ。
腐ってやがる、早過ぎたんだ。

復活させようにも今度はVMware Infrastructure Clientがダメポで
コンソールが正常に表示されるまでに時間がかかり過ぎる上に
キー入力をその間受け付けないせいで、boot promptで
Single Userを選択する間もなくタイムアウト、オーワタオワタ。
BIOS画面からして出すの至難の業なんだが…もうManagement Consoleに戻してくれ…

回避方法、起動オプションのパワーオン時起動遅延がデフォルト0なのを
最大の10,000msにするか、強制的にBIOSセットアップにチェック入れる。

インストーラーはWAPBL有効なのか、 これじゃ救助できん罠。
boot時にWAPBL無効にできるようにuserconf可能にするか
WAPBL投したfixit floppy image用意してもらわん事には困るよな。
fsck(8)で直った。

とゆーかんじでモチベーション、ガンガン ズンズン グイグイ低下中。

[NetBSD] new locale db for 5.0

相変わらずVMware他の環境問題(エコに非ず、oh〜Mercy Mercy Me)で
TODOs消化してないんだけども。

ひゃーchrtbl(8)とかNetBSDにもあったのか、はじめて知った。
いやfile magicが"BSDCTYPE"の旧形式LC_CTYPE locale-dbが存在してるのは
runeglue.cあたり読んだ時気づいてたんだが、ツールもあるとは知らんかった。
ちゅうことでctypeio.cの__savectypeは消しちゃダメだった訳だ。

Makefileのrev1.1からchrtbl(8)自身でctypeio.oをlinkするようになってるので
このシンボルがlibcにある必要はないな、そこだけ切り取ってsrc/usr.sbin/chrtblに移動。
それとmanにLC_NUMERICについての記述があるけど実装はされてない様子なので
fallbackは要らないもより、よかったよかった。

あと先日のpatchだとrescueあたりのbuildでstatic link + __link_set_*の問題でこける様子。
あるぇ、libc.aにたしかに__start_link_set_*とか__stop_link_set_*のシンボルが埋め込まれないね。
(脳内そりゃそうだの大合唱)

これlibpam.aでも同様の問題(openpam_static.c)が発生してるんじゃないかなー、げーどうすんだ。
ぁぁぁぁFreeBSD/DragonFlyのlinker_set.hはどうやって解決してんだろか、 なんか悪寒がする。*1
使えないとなるとちょっとした手戻りで痛いな、やっぱり飛び道具はあんま使うべきじゃないと反省。

そもそもsetlocale(3)はLC_CTYPEがdlopen(3)使うのでstatic binaryでは動かないちゅう
Citrus特有のBUGS SECTIONも存在しとるし、そもそもrescueでlocale使える必要もあんまないので
いざとなったらrescue/Makefileでoverrideしちまうか、手抜き杉。

某所でagc氏に進捗具合を訊かれているようなので、メール書き中。
いろいろlocale dataの中身とlocaleを使用する関数の動作が怪しいので
libcの変更だけでlocale dbはインストールしない方針を相談してみるテスト。
怪しさの秘訣は↓こんなかんじ。

こんな中途半端な実装でリリースしたら恥ずい罠。

それに結局reduce locale db size(*.UTF-8) by iconv + locale.alias問題もアイデア煮詰まってるし。
sodaさんと相談したときはlocale.aliasの文法を変更してもいいやみたいな話だったのだけど
よく考えると古いlibcが新しいlocale.aliasを読んだときにparse errorになっちまうので
やっぱり@modifierの範疇内で何とかしないとダメなんだな。
そうすると@ucs4とか@euroとか、世の中@modifierの使われ方が混乱しとるので調査が必要。
どうしても間に合わない *2

*1:DragonFlyBSDは大丈夫だった、crunchgenの問題かな。
*2:ちゅうか遊びにいくために切り上げたい(←これが一番大きい)

週末

ここんとこ週末になると天気が悪くなる希ガス。

chase these clouds away
i hate this sunless saturday

やぱりEveryday Sunsineだよな。
ということで急に Fishbone聴きたくなってきた、CD買い直すか。
キーボードのChris Dowdもう脱退しちゃったんだっけか。

やっぱりかっちょいい。
ちなみにこの人のキーボードスタンドは一本足を軸に360°回転する特注品。
意味無くクルクル回す( 0:10あたり) のがシュールで好きだった。

コレジャナイロボがグッドデザイン大賞受賞、ワロタ。

JTC1/SC22/WG14ヲチ

新しいのでてたのか、でもあんまネタ無いな。

気になるとこだけ。

他にも旧来char *を返す関数をconstつきにしようとか、POSIXの関数をC標準にとか。

ISO/IEC TR19769とかC1X入ったらCitrusも対応せんとならんか、いやだいやだ。
Normalizationもまともに扱えないAPI入れる必要あんのかと小一時間(以下略

C1Xはcompiler matterが割と多そうだからpcc(1)涙目か。

まぁ先の話だけど、おいらもmulti-localeとかLC_COLLATEとかmultibyte regexが終わったら何やるかね。
引退ネタ的にはBSDL liblayoutとかBSDL gettext-toolあたりか。

今時liblayoutなんぞ実装して誰が嬉しいのかという噂もある、libX11ごとforkするならまだしも。
あとはOpenMotifがliblayout呼んでる部分もソース公開するとか、それこそ誰が嬉しいんだ *1

gettext-toolはもうGNUとかLSBが手綱持ってる限りウンコ塗り続ける作業が待ってるだけだしな。

その前にlocaledef(1)があったか、労多く得られるのはUNIX(TM)にまた一歩近づいたという男坂、にんともかんとも。

*1:オレオレ。

2008/11/18(Tue)

[C1X] char{16,32}_t

kbkさんとこ。
char{16,32}_tはC++0xが先行してますやね(だからとばっちり)。
ただCの方でも既に 何年も前から TR 19769として提案されてます。
原案の出所は知らないのですが、最近Plauger先生が率先してる様子。
# たしか何年か前にも今は亡きCマガの連載でも触れてた記憶。

まぁ日本CSI主義者同盟wとしましては
wchar_t=UCS4つまりUnicode hardwiredを前提とするような
到底受け入れられないシロモノ *1とは違って
(まぁ__STDC_ISO_10646__というアレなもんあるけど)
char{16,32}_tとして別のcharacter typeを導入するのには特に異存はないのです。
# まぁとんでもなくダサいとは思いますが *2

しかしなんといってもこのTRで定義されてるAPIsが使い物にならないのですよ。
c{16,32}rtomb/mbrtoc{16,32}なんぞ機能限定超劣化版iconv(3)に過ぎないわけでして *3
こんなんを只でさえクソややこしいlocale周りに追加する必要性がどこにあるのか
小一時間問い詰めたい。

他にもchar{16,32}_t用のis*やto*相当の機能がごっそり欠けてて使いものにならんとか。
それとも c{16,32}rtomb -> mbrtowc(3) -> iswctype/towtrans というアレなことするんかと。
こういう不完全な状態でC1Xに突っ込まれると、みんな手抜きして

	char32_t c32;
	const char mbs[] = ...
	mbstate_t st = { 0 };
	int len;

	len = (int)mbrtoc32(&c32, &utf32str[0], sizeof(utf32str), &st);
	if (len < 0)
		abort();
	if (!iswspace((wchar_t)c32)) { ← 勘弁してください
		...
	}

とか目も当てられないコードが量産される悪寒、やーめーてー。

他にもそれこそBOMやらNormalization、IVS、multibyte <-> char32_tでM:N変換(以下略
そういう不備は何度も指摘されてたはずで、それゆえにsuspended状態だと思ったのですが
いつの間にかC++0xがリーチかけてやがるので、C1Xにもなし崩し的に入っちゃうのでしょう。

前もちらっと書いたけど、結局mbrtowc/wcrtomb(3)もiconv(3)もどうしようもないウンコなんですよ。
あんなものアプリ書く人間が直接触るのはもっての外で、やるならMSVC++のように
fopenを拡張するほうが何ぼかマシ。

	FILE *fp;
	wchar_t wc;

	setlocale(LC_CTYPE, "ja_JP.eucJP");
	fp = fopen("utf32le.txt", "r,ccs=utf32le");
	wc = fgetwc(fp);
	...

つー感じっすかね(ほんとはlocale_tがいいのか)。

んでこれと一緒にglibc2由来のTR24731-2、open_memstream(3)やfmemopen(3)
(当然こっちもencoding指定可に拡張する)も導入すれば
stdioがJavaで例えるならjava.io.{Reader,Writer}のように扱えるんですが。
こういうコンセプトならiconv(3)はfread/fwrite(3)の内部実装用にだけ存在すればいいわけですし
mbrtowc/wcrtomb(3)もfgetwc/fputwc(3)の内部実装(以下同文)なわけで。

んで結局はこれMSVCの16bit wchar_t問題をどうにかするべく

#ifdef WCHAR_T_AS_16BIT
#define char16_t	wchar_t
#define mbrtoc16	mbrtowc
#define c16rtomb	wcrtomb
...
#else
#define char32_t	wchar_t
#define mbrtoc32	mbrtowc
#define c32rtomb	wcrtomb
...
#endif

程度のことしか考えてないんじゃないかと疑っちゃうんですよね。
つまりMSVC以外では何の役にも立たないシロモノなんじゃねかと *4

ちゅうかC++0xの方でchar{16,32}_tのbenefitちゃんと説明してる人っている?
私はC++0xの方はもうありゃアンサイクロペディア級の ネタと思うようにして
最近はもうチェックしてないんだけど *5

更に u8接頭語とかcompiling-time locale問題をどう考えてることやら。
これ要するにPortable Character SetをISO646からISO10646に拡張するってことと同義だよな。
まぁ__STDC_ISO_10646__の場合のみ有効ちゅう話なら勝手にどうぞなんですが
これ原則的には 前も書いたように、互換性の無いencodingではsetlocale(3)できなくなるちゅーことでして。
あぁC標準ではsetlocale(3)無いからどうでもいいのか(ぉあった orz

このあたりのスレッド参照。
要するにもう7年以上前からループしとるわけで。

いつぞやOpenI18Nの樋浦さんはPOSIX localeをobsoleteにする選択肢もある
とまで踏み込もうとしてたんに、またしてもPOSIX localeの改悪ですかと、はぁ。

んでDinkum Threads Libraryについては、Austin Group(要はTOGです)の 反応をお楽しみください。

あ、あとCにmergeされるPOSIX APIsは全部じゃないみたいっすよ、ほんの一部。

*1: CSI wchar_t実装において深刻なバイナリ非互換性を生むニクイ奴
*2:それより s/char/byte/ (以下略
*3:まぁiconv(3)も十分ウンコですが。
b{16,32}toc{16,32}、あるいはb{16,32}towc/wctob{16,32}とかなら
まだ存在価値あるような気がする、でもイラネ。

*4:それにしたってchar16_tでは戻り値(size_t)-3とかあるしなぁ。
*5:もうマ稼業疲れたよ、パトラッシュ…

[NetBSD] __link_set_*

やっぱり__link_set_*変だ、現状libpamの方もstatic linkの場合使えてない感じ。

DragonFlyBSDではcitrus_module.[ch]でlinker_set.hを使ってる。

338 SET_DECLARE(citrus_set, struct citrus_metadata);
339
340 struct citrus_metadata empty = {
341     NULL, NULL, NULL
342 };
343
344 DATA_SET(citrus_set, empty);

なので

$ nm /usr/lib/libc.a | grep citrus_set
	U __start_set_citrus_set
	U __stop_set_citrus_set

ちゅう具合にlibc.aには__{start,stop}_set_citrus_setがUシンボルとして存在する。
でもNetBSDの場合と違って

$ cat > test.c
#include <locale.h>
int
main(void)
{
	setlocale(LC_ALL, "");
}
^D
$ gcc -static -o test test.c

としてbuildしてもundefined symbol errorにならない。

$ nm test
08060028 A __start_set_citrus_set
08060034 A __stop_set_citrus_set

ちゃんとあるんだよな。

今回のmulti-locale実装での__link_set_*の仕様は↑とやってることは一緒なので
rescueのbuild時にundefined symbol errorが発生する理由が判らん、トホホ。

とりあえず__link_set_*使うの止めようかな、別に本質的ではない遊びだし。

[C1X] 続char{16,32}_t

ちょっと補足。

基本的にC++0xにおけるchar{16,32}_tを批判しとるのではなく、C1XのTR 19769を批判してます。
C++だとcodecvtはおそらくc{16,32}rtombのようにMB_CUR_MAXの制限を受けないと思われるので
Unicode Normalizationなんかに支障ないような気がしますが、まぁあっちは仕様読んでないし。

強調しておくけど、char{16,32}_tのようにwchar_tと別の型を用意することはむしろ歓迎。
C99での__STDC_ISO_10646__のようなwchar_tをハ〜イジャックするような行為が異常だった。

しかしtypedef typedef char16_t uint_least16_tとかやっとる時点でMD(machine dependent)だし
host-endianちゅー問題もあるので、wchar_tへの不満の多く(ネットワーク透過とか)は解決できてない。
wchar_tもchar{16,32}_tも、どっちみちserializeしようと思ったらmultibyteに戻さざるを得ないのよね。

残るメリットとしてはwchar_t + __STDC_ISO10646__環境でなくてもchar{16,32}_tの中のUnicodeの値を
直接参照可能ちゅうことですが、そもそも__STDC_ISO_10646__を推進したUnicode loverですら
Unicode直値を扱うのはGTK+2やQTなんかのUI Toolkitの内部実装目的のみであって
一般のアプリケーションプログラマには使わせることは本意ではないといっとったはずなんですがね。
こんなpublic typeにしたらどんな悲喜劇待ってることやら :D

んでこんなアホなものに時間かけるくらいなら、IBM ICUあたりをC標準にして
さっさとPOSIX localeをゴミ箱放り込むべきちゅー話はもう何年も前から。

[NetBSD] 続 __link_set_*

スマソ、俺の使い方が間違いだった。
__link_set_declしとるobjectの中で__link_set_add_*「も」しないとダメな様子。
さっきのDragonFlyBSDのコード内でdummyをDATA_SETしとるのはその為だったもより。
多分これでrescueの下もbuildが通るようになりそだ、そしたらagc氏に返事投げる。

2008/11/19(Wed)

[NetBSD] mutt + Citrus iconv

tamoさんとこ。

エラーが発生するのはLANGがUTF-8 localeの場合ですね。

んで

s/KS_C_5601-1987/EUC-KR/g

とかすると問題なく動作するので、iconv_open(3)に失敗した時にどっかで無限ループしてる悪寒。
んでiconv_open(3)はサポートされないCES名を渡された場合、(iconv_t)-1を返しますが
muttはこれまともにチェックしてない部分が散見されますねぇ。
iconv handleをあちこちでたらい回ししててよく判らん...

まぁiconv(3)に無効なハンドル(iconv_t)-1を渡した場合に
Citrus iconvが内部で無限ループしちまってる可能性もあるのですが
ちゃんとCitrusチェックしてるのでそこは無罪。
そもそもこのケースって、仕様では戻り値やerrnoとか定義されてなかったはずです。
よって「未定義動作」ですからあくまでアプリ側で注意する問題だと思います。
iconv_open(3)に失敗したらその無効なハンドルでiconv(3)を決して呼ばないように。
シトラスワルクナーイ。
まだワカンネ。

んで、このサポートされてないKS_C_5601-1987というMIME Encoding名は
IANA Charset Registory由来でしょうが、そもそもiconv(3)の仕様とは無関係です。
(つかそもそも仕様で何も決まってないというところがiconvのウンコたる所以)
iconv_open(3)に渡してもKnown Nameであるとは限らないので、mutt側で

ks_c_5601-1987 -> EUC-KR

とiconvが理解できるようcanonicalizeした上でiconv_open(3)を呼ぶ必要があります。

まぁそれもめんどくさいでしょうし、手っ取り早くは

# cd /usr/share/i18n/esdb
# echo "ks_c_5601-1987    EUC-KR" >>esdb.dir
# mkesdb -m -o esdb.dir.db esdb.dir

とやって、Citrus iconv側でKS_C_5601-1987とEUC-KRをエイリアスにしちまうですな。

以下おまけ。

GNU libiconvの場合KS_C_5601-1987をサポートしとるのですが
これイコールEUC-KRじゃなくてもろRAWコードなんすよね。
だからEUC-KRのISO646-USの文字は全て変換エラーになると思われるのだけど。

$ echo hello | iconv -f KS_C_5601-1987 -t JAVA
\u7325\u58f9
iconv: (stdin):1:4: cannot convert

でもちゃんと動いてるらしいちゅう報告あるのがふしぎ、muttこわい!
どんなiconv(3)の使い方してんだよ…

今日

pkgsrc/mail/mutt-develでPREFER.iconv=pkgsrc有効にならんにゃ。
だもんでFedora8上のbootstrap-pkgsrcで試してみたけど問題なさげ、なんぞそれ。
ちゅうかiconvが問題なのならja_JP.eucJPでも発生するはずでja_JP.UTF-8だけ
ハングするちゅうのが謎すぐる。
つかデフォでLDFLAGに-sいれんなよなぁ。

そもそも4.0 -> 5.99.02でiconvのソースに手を入れた所って
cosmetic changeしかない *1んだよな、となるとncursesかwcwidthの問題かのう。

ちゅうか全裸で草原を駆け抜けるようなフリーダムさのiconvの使い方されてて
ソース追うの苦痛すぐる、charset.cでwrapしてる意味ねぇだろこれ。
やっぱり[お察しください]にiconv使わせたら負け。

TODO、char{16,32}_tに対抗して、char{9,18}_t、c{9,18}rtomb/mbrtoc{9,18}のドラフト書く。

だいぶ前にCHAR_BIT=9な環境向けにUTF-9なctype/iconv moduleは 書いてあるんだが
これをcommitしようとするとNetBSD/pdp10復活させないとならない諸刃の剣。

毎日の記者はν速でスレ立てるとこから練習だな。

*1:仕事して無さ杉。

[NetBSD] 続 mutt

結論としては、mutt_filter_unprintable()内で無限ループしてた。
ちゅうのもmbrtowc(3)の使い方がmutt腐ってるから。

491   memset (&mbstate1, 0, sizeof (mbstate1));
492   memset (&mbstate2, 0, sizeof (mbstate2));
493   for (; (k = mbrtowc (&wc, p, MB_LEN_MAX, &mbstate1)); p += k)
494   {
495     if (k == (size_t)(-1) || k == (size_t)(-2))
496     {
497       k = 1;
498       wc = replacement_char();
499     }

というように、iconv変換で失敗したmultibyte array(実際はeucKR)を
現在のlocale(UTF-8)と勝手に解釈してmbrtowc(3)で変換をかけるのだけど(アホか)
結局これEILSEQになるのでk == (size_t)-1に引っかかるわけっすな。
その場合には代替文字と置き換えを行うのだけど、この時忘れてはならないのは
変換に失敗したときのmbstate_tは「未定義」であるちゅーこと。
http://www.opengroup.org/onlinepubs/009695399/functions/mbrtowc.html

...
(size_t)-1
   If an encoding error occurs, in which case the next n or fewer bytes
do not contribute to a complete and valid character (no value is stored).
In this case, [EILSEQ] shall be stored in errno and the conversion
state is undefined.
...

本当はここで全ての処理を諦めないとあかんのだけど、まぁどうしても
keep goingしたけりゃ一度mbstate_tを初期化状態に戻す必要がある。
でもmuttはそれやってないちゅうことだ。

これcitrus_utf8.cのお行儀が若干宜しくなくて lib/36938でも書いたとおり
変換中のmultibyteをmbstate_tに格納した後にvalidateをかけて
不正なバイトだったらmbstate_tを初期化せずに放置するからなんだよな。
初期化せずに再度mbrtowc(3)を呼ぶと、"\0"に到達したときも
ゴミ1byte + "\0"をdecodeしようとするのでやっぱりEILSEQになっちまうのよね。
そうするとloop脱出条件の (k = mbrtowc()) != 0が永遠に止まらないわけでして。

--- mbyte.c.orig        2008-11-19 19:27:28.000000000 +0900
+++ mbyte.c     2008-11-19 19:40:42.000000000 +0900
@@ -496,6 +496,7 @@
    {
      k = 1;
      wc = replacement_char();
+      memset (&mbstate1, 0, sizeof (mbstate1));
    }
    if (!IsWPrint (wc))
      wc = '?';

一件落着。

ちゅうか最近ここにウンコ書き過ぎ、自重。

2008/11/20(Thu)

[pkgsrc] 続々 mutt

撃墜確認w

本来はiconv(3)で失敗した時点で「ワッフルワッフル」でも[お察しください]でも
お好きな代替メッセージと差し替えた方が安全なんですよね。
あるいはbase64 decodeを実行する以前の[+/A-Za-z0-9]+のまま表示するとか。

ジャンクな不正バイト列を強制的に別の文字コードのマルチバイトとして解釈しようと考えるのは邪悪で
時に IEの文字コード自動判定 + UTF-7によるXSS脆弱性のようなウンコな事態を引き起こす元凶ちゅー
反省が念頭にあるのですのよな。

やっぱり「なんとなくだけどスパムの中身が読める」便利(?)よりも、ここは安全側に倒すべきとこだと思います。
# まぁ歴史的な問題で、MUAは文字化けメールを修復できて当たり前な風潮ありありなのも困りもんですが。

っても今回のmuttのコードが元で攻撃が可能ちゅう事はないんですが。

もし

From: ?Unkode-5.1?B?K0FEdz94bWwgdmVyc2lvbitBRDBBSWctMS4wK0FDSSBlbmNvZGluZytBRDBBSWct=?=
 =?Unkode-5.1?B?VVRGLTcrQUNJPytBRDRBUEEtaG9nZS8rQUQ0Cg==?=

ちゅーメッセージがもしも攻撃コードになりうるのなら

From: +ADw?xml version+AD0AIg-1.0+ACI encoding+AD0AIg-UTF-7+ACI?+AD4APA-hoge/+AD4

とか普通に送信してもヤバイわけでして :D

<?xml version="1.0" encoding="UTF-7"?><hoge/>

しかしmuttのようにコード変換に関するコードがあちこちに播種しとる状態の
パスタソースを弄る場合は、用心するに越したことないと思います。

[C言語] mbrtowc(3)を正しく使おう[初級偏]

よく目にするよくないコード例。

@ 実行結果を戻り値のみで判断する

	len = mbrtowc(&wc, s, n, st);
	if (len == (size_t)-1 || len == (size_t)-2)
		abort();

実は 仕様書を注意深く読むと、SUSv2 -> SUSv3でひっそり仕様変更があります。

The [EINVAL] error condition is added.

んでERRORセクションを読むと

[EINVAL]
	ps points to an object that contains an invalid conversion state.

とあり、不正なmbstate_tを食わせた場合はerrnoにEINVALをセットするとの記述が追加になってます。
そしてこの場合、戻り値として何を返すかRETURN VALUEセクションに記述がありません。
記述が無いすなわち「未定義」です。 よってこのerrorを正しくcatchする為には

	len = mbrtowc(&wc, s, n, st);
	if (errno == EINVAL || len == (size_t)-1 || len == (size_t)-2)
		abort();

としてerrnoを確認するべきなのです、うぼぁ。

今回のmuttのようなmbstate_tを初期化せずに使用してしまうことによるバグを燻り出すのに
malloc(3)のJオプション(heapをゴミで埋めるので初期化せずに確保したメモリを使うとエラーになる)
と同様に、EILSEQの場合mbstate_tをゴミで埋めちまうという手を考えたのだけども
そもそも誰もEINVALをチェックしてないから意味がないという orz

(追記) 塩崎さんから ツッコミ
戻り値による成功/失敗の判断のあとに失敗原因としてerrnoをチェックするという原則に
反するので、仕様のバグでしょうということ。
ということで忘れてください :D

	len = mbrtowc(&wc, s, n, st);
	if (len == (size_t)-1 || len == (size_t)-2)
		abort();

のままで問題ありません。

@ 変換がnul文字('\0'つまりmultibyteの終端)まで到達したかの確認を、戻り値を使って行う

	for (;;) {
		len = mbrtowc(&wc, s, n, st);
		if (errno || len == (size_t)-2)
			abort();
		if (len == (size_t)0)
			break;
	}

mbrtowc(3)を繰り返し、'\0'まで到達した場合はループを脱出するちゅうコード例です。
len == (size_t)0の場合にbreakしてますが、さてこれのどこが悪いのか?

確かに仕様書のRETURN VALUEの項には

0
    If the next n or fewer bytes complete the character that corresponds to
    the null wide character (which is the value stored).

とあるので、上記のコードは全く問題はないように思えます。

しかし実はこの仕様に対する バグ報告がJTC1/SC22/WG14に何年も前から提出されてるのですよ。

このバグ報告(DR#288)を今北産業すると

	wc == L'\0' の場合、 len == (size_t)0

は「真」であるけども、その逆

	len == (size_t)0 の場合、wc == L'\0'

は「偽」であるちゅー証明です、あぁ1行多かった。

ただこれ証明に使ってる例が最悪なのよね。
wchar_t as UTF-16という「いや、そのりくつはおかしい」ケース *1を以って説明してるので
これはバグじゃないもん!つーことでClosedにされちまったみたいですな。
なぜwchar_t as UTF-16がダメなの?ちゅう理由は 過去の記事を読んでちょ。

しかし実際のところ↑は、 zW(簡体中国語)、 VIQR(ベトナム語)等のstateful encodingでも発生するのですよ。
詳しくはリンク先参照。

まぁ現実問題、この手のstateful encodingは Portable Character Set非互換なケースが多く
ふつーPOSIX localeであれば無視してもOK(使ってる人もまず存在しないし…)なのですが
ことC標準においては、こいつらを実行時文字集合として採用することを禁ずる理由は無いとゆう。

ですので、ここはどーせなら安全側に倒して

	for (;;) {
		len = mbrtowc(&wc, s, n, st);
		if (errno || len == (size_t)-2)
			abort();
		if (wc == L'\0')
			break;
	}

wc == L'\0'をループ脱出条件にしちまうほうが磐石です。
# ちゅうかmbstowcs(3)かmbsrtowcs(3)使え。

まぁmbrtowc(3)がL'\0'を変換したときにわざわざ0を返すのはあまりにもウンコ仕様なのだけどな。
ちゅうのも次に説明するような頭の痛い問題があるから。

@ nulワイド文字(L'\0')に変換されるバイト列の長さは、stateful encodingの場合必ずしも1ではない

これは 過去記事を読んでくだしい、特に補足する話も無いので。

@ 次回予告

wcrtomb(3)を正しく使おう[初級偏]を予定してますが、時期は未定ちゅうことで。

*1:ただchar16_tなるアレなものを導入しようとしてるのは、このDR#288が原因なのは間違いないと思われ、アホだ。

今日

花屋、血の色をしたガーベラ。

ウン国際宇宙ステーションで工具紛失
以前は カメラ紛失したよな。
虚空に消えるカメラがフランク・プール(2001年宇宙の旅)っぽい。

planet earth is blue, and there's nothing i can do

この映画をモチーフにしたDavid Bowieの"Space Oddity"、これの歌詞対訳なんだけど

your circuit's dead

を「君は死に取り囲まれてる(うろおぼえ)」とか訳してた記憶があるんだが
これ普通に「君の(宇宙服の)回路が故障してしまった」だよなぁ。

3001年終局への旅だっけ? プールが宇宙人に拾われて復活するちゅう無茶苦茶な話は。

ashes to ashes, funk to funky, we know major toms a junkie

やっぱり続編って難しいよな。

2010年の映画は、字幕の例の有名な人が

i was david bowman

を「私はボーマンだ」と訳してて噴いた記憶がある。
「昔ボーマン、今スターチャイルド」という"was"にこめられた意味がもうキレイサッパリ。
ちゃんと過去形で訳さないと、あのガブちゃんなんか困るでしょ(謎

christos_time_t枝のcommitで大体終わったぜみたいなコメントが書いてある希ガス。
早いとこ32bit _ctype_ tableとかunsigned int wchar_tの話しないとならんなぁ。
ちゅうかその前にagc氏への返事を完成させないと阿寒のだけど。

なんじゃこりゃ、5.0になんかpullupきてんのね。

$ LD_PRELOAD=/usr/src/lib/libc/libc.so.12.163 perl
perl: _lwp_ctl: Memory fault

こういう枝切ってからABI変わる場合って、kernelもlibcもversion変更できないから困るよな。

あんまモチベーションが上がらないので、multi-localeでstrtol使っちゃダメ問題は
_citrus_bcsに相当品を追加することで回避することにした。

localeioはcitrusに依存してはならんので、この_citrus_bcs_strtolを利用できないけど
そこはまぁもうシラネちゅうことで放置。

本当はcitrus_euc.cがparse_variable()中で使ってるので
length checkありのstrtoul相当品を用意しないといけないのだけども
まぁlengh check無しを使ってもまず問題にならんのでそこは日和った。

citrus_prop.cの中でlength check付というか_citrus_regionを引数にとる
strtoulのuint64_t版(_citrus_prop_read_num)ちゅうものがあるにはあるのだけど
exportしてない && libcでは持たずにcitrus_propを使いたいencoding module(hz, big5)
だけがlinkしている状態なんでこっちは使わせたくないんだな。
将来的に両者をunifyする方向で、つかmulti-localeが入ればcitrus_bcsは必要なくなるか。

2008/11/21(Fri)

今日

lib/39986 どうみてもtoolchainです。
libgcc_sが変とかかなぁ。

pcc-listでもcompiling time localeネタをしてるような気がするが読む気力が無い。
xtermという単語がでた時点でパワーゲージ半減するからな。

pcc-listは別にcompiling time localeの話じゃないのか、どうでもいいや。

昼に仕事ちょっと抜け出して、川崎幸警察署に 出頭落し物の受領にいってきた。

場所知らんので署のホムペとストカービューで位置を確認したのだが
そもそも私はスイーツ(笑)脳であて地図が全く読めない+方向感覚ゼロ(営業時代は苦労した)。
南武線で2駅先(矢向駅)と把握、ふっしぎだなーなんでこんな縁もゆかりも無い土地で発見???
まさかスリか?スリなんだな!とフットーしそうになりながら川崎駅より南武線乗車。

窓口で手続を終えて外に出てみると、直ぐ目の前にラゾーナにソリッドスクエアが見えるじゃないの。
おかげでまた財布落としそうになった、現場のビルから徒歩でおkな距離じゃねーか。もうダメだ俺。

コンビニ。
458円の買い物に5058円渡したらお釣りが100円だった、な…何を言って(以下ポルナレフAA略
レジ558円と打ち間違えたとこまでは許すが、表示されるお釣り金額とレジに納めようとする金額が
明らかに一致してない風の息づかい感じてほしいなりよ。
脊髄反射だけで仕事しとる店員こわい>< まぁ方向音痴と同じで金額音痴というのもあるのだろう。

一方、新渡戸稲造 *1じゃなくて岩倉具視を渡しちまったか?と思った俺はオッサン、もうダメだ。

*1:樋口一葉です。

[C言語] strto*, mbrtowc(3), errno

strto*がダメな件
個人的には

が欲しいかな。

いずれにしても strtoi() は必要だろ JK。 

そこでatoi(ぉ

こういう「正常値と区別がつかない戻り値でも errno が有効なケース」というのも
あるので、ひょっとすると mbrtowc() の例も仕様書のバグではなくて nozaki さん
の解釈が正しいんだったりして。

MB_LEN_MAX == SIZE_T_MAX ですか :D
1ワイド文字変換するのにSIZE_T_MAXまでmutibyte消費するケースすなわち
冗長なエスケープが許容されるCESの場合は、MB_CUR_MAX=∞であるからして
その可能性を考えて今の仕様…ないわー。
おっしゃる通り戻り値に(size_t)-1をセットする方がよっぽどreasonableですし
これは仕様バグなのでしょうね。

エラーの返し方がダメな件の反省は、TR24731-1なんかで
errno_tを返すというデザインの統一の試みがありますね。

errno_t
memcpy_s(void * __restrict s1, rsize_t s1max,
        const void * __restrict s2, rsize_t n)

まぁstrnlen_s()とかstrtok_s()なんかは使いづらくなるので旧来のデザインのままですが。

2008/11/22(Sat)

今日

5.99.03だか5.99.3だかにkernel入れ替えたらroot filesystem認識できずに焦った。
これが原因か、kmod有効にしたから全部そっち使うようにした && ドサクサに
多分 kern/39875が原因で「二人が入り、出るのは一人!」と
マッドマックス・サンダードーム宜しく options SOFTDEP 投されたちゅうこと。

つかcurrent-userにHEADS-UPも出てないようだし
そもそもWAPBLもまだ信用ならん(つかvfs全体なのか?)状態だから
こういうのはもっと慎重にやって欲しいわ、へなへな。

それとbuild.shにlkm/kmodターゲット無いのが困る。
ちゅうかbuild.sh kernelで一緒にinstallしてくれんと
今やFFSすらkmodなので、今回のようにbootすらできん状態になる。
options FFSくらいは最低でもbuiltinにしとくべきだよな。

modload/modunloadもsuffixが .lkm <-> .kmod かで互換性無いんだっけか。
ますますHEADS-UP書こうぜ。

こうして無駄な時間が過ぎていく

みたいな

ちうゅか冷静に考えて、kernelはroot filesystemを読む能力が無いのに
どうやってkmod読む気なんだろね、もしかして最近変更のあったみたいな
boot loaderがよきに計らってくれんのかいな。

めんどくさいからGENERICのoptions FFSとoptions SOFTDEPだけ元に戻して
リコンパイルすっか。

と思ったらad氏が[HEADS-UP]でなくHeads up:というsubjectでメールきてた orz
やっぱboot入れ替えるのね。

src/sys/modules/ffs/Makefileに-DSOFTDEPいれて作り直すかいの。
ところで一時期ftpクラッシュ連発させてたUSE_DIRHASHが有効になってるんだが
直ったのかいな、これ。

TODO追加、chiristos_time_t枝をチェケラしとくこと。
ERAの実装がまだなのでまず大丈夫だと思うけど、LC_TIME関連が何かがあるかも。

つかそもそもtime_tは64bitで足りるのか。
前も書いたが、IBMが弥勒菩薩さまが出現するより
遥か未来からタイムマシン使ってLinux Kernelに commitしてる件。

弥勒様がプロマネじゃ、その頃には俺らとっくにお亡くなりになってても
黄泉比良坂リサーチパークで西暦2900億年対応の為に閉じ込められるだろJK。

2008/11/23(Sun)

[NetBSD] new locale db for 5.0

モチベーションがあがらないけどbuild.sh {build,install}通ったので
某所にメール投げた、これ先日書きかけた下書き紛失したので
一から書き直しで、全俺が涙した。

ちゅうわけで最新版の patch
排他でlock忘れとかポカしてたのが最近のlwp周りの修正で発覚したので
赤面しながら修正したのと、magicの他にuint32_tなversion番号を持たせるようにした。
magicだけで新旧判断だとcitrus_db_open()のI/Fじゃやりにくいからね。
どうせすぐにLC_TIMEあたりは項目追加になるからな。

んで結局LC_*のsubdir化はbsd.*.mkとかも弄らんとならなそうだし
そもそも既にLC_CTYPEはモノリシックなので以前localedef(1)に関して
tech-userlevel@に投げた ネタはどっちみち実現できんからね。
それに5.0に間に合うなら、plain textなlocale-dbとの共存なぞ考える必要ないしな。
んなわけで止めた。

さて某スレにもなんか書いたような気がするのでnvi-1.81をまともにする作業に帰るか…

まぁ自爆なんだがtech-userlevelでアナウンスしろと。it can't hurtだろと某氏。
俺の英語力が痛いんじゃwww

2008/11/24(Mon)

[NetBSD] new locale db for 5.0

すっかりMB_CUR_MAXのこと忘れてたので_locale_cache_tにそれ用のメンバ追加した patch
まぁ無くてもいいんだけど、将来的に性能の話になると_locale_cache_tくらいは
public typeにしてglibc2みたいにマクロでinlineにせにゃならん可能性もあるし。

んでmulti-localeの方も 更新、上のpatchのあたった状態のlibcで動作しやす。

さて、pthread_tにper-thread locale_t用のフィールド追加するよか
Thread Local Storage実装するのが筋なんだがどうすんべ。

いきなりnviスレで秘孔突かれた、結合文字で表示が崩れるってまぁそうだろうな。
理論的にはterminalが対応してればwcurses関係無しにOKなはずなんだっけか。
でもcursorの移動あたりはwcwidth(3)じゃどうにもならん悪寒ガス。
やっぱUnicode捨てようぜ。

つかcurrent-userでbouyer氏がviが固まるゆーちょるな。
mbrtowcなんかの使い方がヘボイからなぁ…

[NetBSD] pcc(1)

pcc-listにwide-character対応patchとやらきとるが、メールが読みづらくて俺涙目。
つかこれ__ISO_STDC_10646__じゃねぇか、MirBSDは[お察しください]だな。
他の*BSDサポート全滅させたいのかと小一時間。
しかもmultibyteはUTF-8固定かよwwwこれだから[お察しください]は困る。

構ってる時間もないしなー、これcommitされるようならサヨウナラだな。
なんかragge氏もこないだtech-userlevelでソース文字集合はUTF-8がいいみたいな
アレなこといっとったような気がするからちょっと怖いな。

つかもう手一杯です。

Universal Characterあたりの部分はCSI wchar_tだとcross-compiler考えると氏ねるからな。

そもそもMirBSDは16bit wchar_tでC localeがUTF-2(UCS2レベルのUTF-8)ちゅう
アレな実装してるくらいだから、i18n周りは触らせちゃダメだって。

CSI wchar_t + cc(1)

cc(1)の実装を考えるとCSI(codeset independent) wchar_tは
確かにいろんな点でメンドくさくはあるね。

まず第一に実装依存のopaqueなwchar_tの値の方はcc(1)は一切知ることできない。
んなわけでそこはlibcにお任せするしかないのだが、libcにあるのは
setlocale(3)とかmbrtowc(3)とかのショボイ関数ばかり。

まぁold schoolなcc(1)ちゅうのは、自身が起動された時のlocaleを
元にソース/実行時文字集合を決定するだけの話なので
この手のショボイ関数でも全く問題はずなんだけど、ホントは。

でもgcc(1)の--input-charset/--exec-charasetのように
cc(1)自身のlocaleとは異なった文字コードを扱おうとすると
途端にmbrtowc(3笑)は使い物にならなくなるわけ。

例えば

LANG=ja_JP.eucJP cc --input-charset=CP932 --exec-charset=UTF-8

で起動したら、cc(1)自身の為のsetlocale(LC_CTYPE, "ja_JP.eucJP")と
実行時文字集合の為のsetlocale(LC_CTYPE, "ja_JP.UTF-8")をいちいち切替ながら
動作せんとあかんわけで(CP932 -> UTF-8への変換はiconvでOK)、とてもじゃないけど
現実的にそんなコードは書きたくないわけ。

まぁ今私がNetBSD向けに実装してるようなmulti-localeの機能があればマシなんだけど
こいつはそもそも標準関数じゃないので、移植性の問題がある。
一応C++ならmulti-localeは標準だけど(よってgccをC++で書き直す試みはある意味正しいw)。

それにcross-compiler的なものを考えると今度はmulti-localeすら役に立たないわけ。
NetBSDホストのmbrtowc_l()を使ってglibc2ターゲットのwchar_tに変換はできませんがな。

GNU libiconvあたりだとiconv_open("WCHAR_T")とかマダファッカなもんあるから
それに飛びついちまう人もいそうだけど、あれは所詮UCS4に変換するだけなので(以下略。

このあたりで「何でwchar_tはUCS4じゃ無いんだ」とかキレる香具師も出てくるんだけど
そこはもう歴史的な問題であって、Cは元々内部コードを規定していないからね。
それこそEBCDICなホストとかもあるのよと。

まぁ SysV MNLS仕様あたりはEUC hardwired wchar_tで
wchar_tの内部表現は規定してたけど、これもUCS4 codepointとは互換性ないからね。
そしてSolaris/SunOSをはじめとして数多くのlibc実装がCSI wchar_tを採用しているという
事実から目を背けられても困るという。

こっちの世界の人間からすると、互換性のない__STDC_ISO_10646__なんてのは
[お察しください]で[お察しください]が[お察しください]なわけでして。
まぁ抵抗したからこそ、当初wchar as UCS4をmustにしようという話が
事前定義マクロが定義されてる場合のみという落としどころになったわけですが。
これどっちも負けだね。

それにwchar_t as UCS4だとUnicodeの筋の悪さをもろにその影響を受けるし。
mbrtowc(3)呼ばれるたびにJIS -> UCS4の変換テーブル引くんだからそりゃアプリも遅くなる罠。

それに包摂規準がそもそもUCS4と異なる実行時文字集合どうすんだとか
実行時文字集合とUCS4でM:Nマッピングになるケースとかwchar_t=1字という原則壊れる *1だろJK。

んでwcwidth/wcswidth(3)はそもそも結合文字ちゅうものの存在を考慮してないし。
だからcursesのカーソル移動が変になるわけで、もうね(以下略

BOM(笑)

話を戻して、結局cross-compilerもOKなナウいcc(1)を作るのであれば
もうこの辺はモジュール化しかないんだろね。

それこそインタフェースだけ定義し、あとはそれぞれのOSに移植する人間が
手前らのwchar_t実装に合わせて勝手に書きやがれ、以上と。
それでで問題ないと思うんだけどな。

POSIX localeを採用しとるOSなら、実行時文字集合をPortable Character Setとし
アプリケーションはsetlocale(3)を呼ぶことで、PCSとと互換性のあるCES/CCSに
切り替えるという仕組みだから、cc(1)が知ってなければならん静的期間中の実行時文字集合
なんぞ、世の中にCES/CCSは山ほどあれど、ほんのわずか。
ISO646とかUS-ASCII、EBCDICくらいじゃないかと *2

んでcc(1)は

OS(NetBSD) + arch(i386) + CES/CCS(ISO646)

あたりをキーにモジュール読み込む仕掛け作っとけばいいんじゃねと。

まぁNetBSD的なMI/MD思想で生きてるので、こういう結論に5分くらいで到達したんだけど
まー某kernelのようにどのarchもi386をemulateするとかやっとるアレな平行世界もあるからなぁ。
まぁ人それぞれだけどさ。

*1:これがc32rtombとその戻り値(size_t)-3なんてもの導入しようとしてる要因、アホだ。
*2:ああMirBSDのUTF-2があるなwww

2008/11/25(Tue)

昨日

相変わらずnew locale db for 5.0いじり、ってもひたすらrelease buildチェックだけど。

あたりを追加、精進がまったく足りません。
さてtech-userlevel@へのアナウンス文面考えるか…

TODO: FreeBSDのThread Local Storageのコード読む。

いい加減寒いのでストーブ出した、しかし一番喜ぶはずのネコはもういぬなぁ。

今日

pcc(1)、tamoさんとこに 例のメールの 訳( その1その2)がwwwご苦労様です。

それにしても

ISO/IEC 9899:1999 (E) を少し読んでみたら、wide character, wide string, and
universal character stuff のほとんどは未定義だったり実装が容易であることに気付いたよ。

未定義だったら世の中libcの実装の数だけwchar_tの内部表現があることに思い至ろうよ…
なぜコンパイラごときが勝手に定義しちゃうのかと、それに俺はBSD fundの支援を受けてないぜ!って
お前は何を言っているんだ

まぁpcc(1)はNetBSDのデフォルトコンパイラじゃないし
そもそも皆スルーしてる?ようなので慌ててはいないのですけどね。

実際のとこgccだってこのへん腐りまくりんぐで、指定しない限りマルチバイトはUTF-8として扱うし
wchar_tは問答無用でUCS4だし、あのpatchがcommitされたとこでgccの現状と対して違いは無かったり。

合体ロボ、kernel方面よくわかんないんだけどminiroot.kmod使うとLinuxのinitrdのように
auto configurationまでやってくれたりすんのだろか。
そうすると後はdevfsがあれば完成だったりするのかね。

softdep、src/sys/module/ffs/Makefileをいじって、ffs_softdep.stub.cでなくffs_softdep.cをbuildするようにして
なおかつCPPFLAGS+=-DSOFTDEPで作り直したんだがやっぱsoftdep有効にならない、はてはて。
まぁ性能的にももはやWAPBLの方が上だしsoftdep使う理由も無いんだけど、安定感がなー。
負荷がかかると結構頻繁にflushに失敗してddb落ちるんだよな。

「日曜やってる病院」を「 月曜やってくる、病院」と誤読した。

2008/11/26(Wed)

昨日〜今日

メール書き、あとでtech-userlevelに流す。

OpenBSD+citrus patch更新、全くテストしてないので experimentalちゅうことで。

今回は7月から私はNetBSDにほとんど何も手を入れてないので(ぉ
その間の差分をmergeする手間が不要なのと、OpenBSD自体の差分も
前回patch用意した時期が遅くすでに4.4のタグが打たれてた頃からなので
ほとんど作業がないので楽だ。

気がつけばedora10が出てたのか、Fedora8がこれでEOLになるんだっけか?
まぁ現場の開発用サーバは既にbluewall linux状態で、提供してるサービス
全てpkgsrcで賄ってるので、すぐに9以降に移行する意向を示す必要も無いけど。

2008/11/27(Thu)

今日

絵文字のユニコード符号化だと。
ああ、いま流行りのGoogle Calendarだと今日は4/1なんだっけ?

ドラフトをざっと眺めてみたけど

くらいのネタは仕込んでおいて欲しかった。

ちゅうかこれ本気なのかwwwwwマジかwwww
ガラパゴスの為にご苦労様です。

でもこれREGISTERD SIGNのU+00AEとU+FEB2Dの重複符号化とか頭痛いよな。

あれ、emoji4unicodeの開発者に元?Netscape/Mozillaの中の人がいる。

Fedora8なんだが、リポジトリがupdates -> updates-newkeyに変更になった後、yumが

error: Couldn't fork %post: Cannot allocate memory

で氏にまくってくれやがるんだが、なんぞこれ。
シャレになんねーアップデートだな…朝からキツイわ 被害者のご心労をお偲びします。

*1:提案されてるUnicode Nameが当り障り無くなってるのにワロタ。

2008/11/28(Fri)

今日

IBMでICUやっとったMarkus Scherer氏も今はGoogleなのか。
ナベツネ巨人状態だな。

久しぶりにOpenBSD起動してCitrus patchのbuildチェック。
NetBSDのbuild.shのように他OS上でもbuild可能ならいいのに(ぉ
ありゃcommitする身にはいつ何処でbuildコケるかビクビクもんなんですが
それ以上にるーるるーメリットあるからねぇ。

sudoでパス間違えると罵られるのがなつかちーですな。
でもssh2で繋いどると時々固まるちゅうか反応が悪くなるのだが、なんぞこれ。

まぁNetBSD tech-userlevelに投げるメールの仕上げから逃避してるんですが。

edoraはyumだけ先にupdateすりゃ良かった感じ。
だが9に更新しようにも10祭りでftp繋がらない。

頭のよい人はむしろ、ひらがなを多用する
あー確かにパタリロと陳恩頼主席の中国語会話風に「我思頭優秀人是多用平仮名」だと
あたまのよさがまるでつたわってきません、すばらしいきじですね\(^o^)/

判り易いでも美しい文章を書くでなく、あえて頭のよいちゅうのが釣り針か。
自分が属してるclassとは異なる文章や言葉づかいに拒否反応が起きるのはもうこりゃ
只の防衛本能だと思われるのだが、そこに優劣持ち込んでくすぐるのがコンプレックス産業。
マル金マルビ(古!)、勝ち組負け組、バカの壁、これみんなおいしい|^q^|です。

2008/11/29(Sat)

今日

ケータイ絵文字がUnicodeに入るなら、ポケベル暗号も標準化しようぜ。
というネタでもと思ったら、既に Perl Moduleがあって アールグレイ噴いた。
つかここはやっぱりopenssl(1)にですね。

悲しき熱帯魚レヴィ=ストロー吸う先生ついに100歳か、久しぶりに読み返してみっか。

それはそうと

構造主義の祖、レヴィ=ストロース100歳に
http://dubai.2ch.net/test/read.cgi/news/1227807887/

337 : マイワシ(兵庫県):2008/11/28(金) 18:29:07.01 ID:NkYd8Sg9
    会計学やってるD3なんだけど、
    恥ずかしながら、いまから社会学と哲学を真剣に勉強したいと考えています。

    必要に応じて場当たり的にツマミグイしてきたんだけど、
    まずは体系的に広く浅く理解するには、何から読んだらいいですか?
    アドバイスお願いします。

    この冬の博論が終わったら1月末から余裕ができるんです。

352 : びわ(東京都):2008/11/28(金) 19:19:38.23 ID:WfasLZCz
    >>351
    つか、D3の人とはいえ
    「デカルト以後・・・」って括りを数ヶ月でやるのは流石にムリだと思う。
    というか、まず越えるべき壁が4つあるわけで。デカルト、カント、フッサールを
    とりあえずやらんとならんでしょ?それにヘーゲル。この辺の理解が甘いまま
    ポストモダン(笑)に進むと、単なる虚無主義系構造論者が一匹完成しちゃうわけですよ。

    何に活かしたいかにもよるけど、とりあえずカント辺りをきちんと抑えることを勧めます。


360 : つまみ菜(千葉県):2008/11/28(金) 19:42:37.14 ID:Q8SqIRoc
    >>351-352
    ここら辺の会話、東大理系院ODの俺には「リリカのおっぱい値を〜」にしか聞こえん。
    文系ってアホだなw

ワロタ。
>>360が「 親族の基本構造」読むと妄想ひろがりんぐ。

2008/11/30(Sun)

今日

とつか再開発君、自爆スイッチ付のタイムマシン…だと…?