某日記

(中期)

平成20年11月11日(火曜日)

査収物

今月入ってからの分。

ヒメギミの作り方(2) / 和泉 明日香

パニクリぐらし☆(3) / 藤凪 かおる

世界樹の迷宮 2 〜六花の少女(上) / FLIPFLOPs

かんなぎ(6) / 武梨 えり

なきむしステップ(1) / カザマ アヤミ

今日

そうか GNU gettext もいつのまにかバージョンがいくつか上がってるんだな。itojun libintl も追従せんとなあ。というか gettext 自体より printf ファミリーのポジショナルパラメータをですね。

どうも Atom ルータマシン上の emacs が Signal 11 でよく落ちる、と思っていたら、いつのまにか make build で make clean してる最中の rm すら Signal 11 で落ちるように。

ルータだからあまり止めたくないなと思いつつ、とりあえず memtest86+ を 10 分くらい動かしてみるかと思って動かしてみたら、10 分どころか 5 秒で結果が出た。

余ってたメモリに差し替えて再度 memtest86+ を 5 分くらい走らせてみたがエラーが出なかったので、念のため元に戻してやっぱり 5 秒でエラーが出ることを確認、アドレスも同じような値なので、メモリチップ不良みたいだな。

余ってたメモリに差し替えて、もう一度 5 分くらい走らせてエラーが出ないことを確認した後、元どおりに設置。メインメモリが 2G から 1G に減ったが大して問題ない。

アキバ事件「誰でもよかった」、これでよいのではないでしょうか - そりゃそうだよなあ。私みたいな馬鹿は最初っから常識的感覚で以って「こんな気違いじみた事件を深く考えても意味ねえだろ JK」で終わらせてしまうわけだけど、中途半端に頭がいい人たちはそれぞれ一家言があるようですね。

たとえばあの事件をトヨタの下請けでこき使われてうんぬん、社会の闇だなんだかんだ言う人もいるけれど、そんなのどうやっても検証できないんですよね。検証できないのを良いことに、「検証できないんだから真実かもしれないじゃないか」的居直りが行われる。まあ頭のいい人には常人に見えないものが見えるのかもしれないけど、しかし、常人に見えないものが見えてしまうってのは、一歩間違えばオカルトですよ。そして、一般の人々は意外とオカルトが好きだったりする。困ったことだ。

そうか、printf は既に入ってましたか。libintl に関しては、GNU gettext tarball の中の NEWS を見ると msgctxt みたいな変なもんが追加されてるような気がするので、ABI はともかく .gmo のフォーマットが変更されてたりはしないのかな、というあたりで、ちょっとソース読んでみないといけないなと。

ただまあ、何が足りないのかもうちょっと具体的に書いてほしいですな。src/gnu/dist/gettext を更新するだけで済んだりして。

「おかんなぎ」って概念がポップアップしたんだがどうすればいいですかね。「今日から妾はそちのおかんじゃ」「『母乳で育てようにも貧乳では無理だしなゲラゲラ』とか考えたであろ」

しかし、いい釣り漫画だよなあ。ナギ様は最初からちゃんと自分が生きとし生けるものの母だと言ってるじゃないか。三巻では妊娠してるし。そちたちは日本神話も読んだことがないのか。

平成20年11月12日(水曜日)

今日

なるほど。しかしソースの大胆さに笑った。LGPL なソースを引用したくないので概要でこんな感じ:


呆れたのを通り越してちょっと感心してしまった。 

まあこれは下手にちゃんとすると「NetBSD ではコンパイルできるのに GNU gettext だとコンパイルできないソース」が生まれそうなので(実害ないけど)、気にせず同じようにすれば簡単に対応できる。他に *pgettext_expr() 系の関数が追加されてるが読んでない。

gettext-tools の doc のドキュメント読んだら、*pgettext_expr() 系の関数は *pgettext() と同じことを文字列リテラルの結合に頼らずにやるバージョンらしい。これらの関数は (libintl.h ではなく) gettext.h をインクルードすると使えるようになるのだが、全部インラインで実装されているのでとりあえず gettext.h だけ gettext からインストールするというのも一つの手ではあるが。

しかしまあ大胆なマクロづかいといえば私もあまり人の事は言えないが。昔作りかけてお蔵入りになってる amstr という C 言語用の単純な(国際化なんて考慮してない)文字列ライブラリでは、構造体を値返しするインライン関数とか、文字列リテラルの長さを静的に取るようにした関数マクロとか、そういううさんくさいものを駆使して利便性を確保したりとかしていた。

参院で田母神前空幕長を参考人招致 -

文民統制をする政治の側にも田母神氏と同じ意見が根強くあることがわかり、政治がコントロールする文民統制が危ういものであることが浮き彫りになりました
俺のコーヒー返せ。

良いチャーチベルの音が手元に無くて困る。

田母神論文問題について

まあこの問題に関しては論点がいくつかあると思うんだよ:

  1. 田母神論文の内容自体の良し悪し
  2. 空自幕僚長という立場上における行動の是非
  3. 文民統制上の問題

1 に関しては、ちょっと軽く流し読みしてみたけれど、私個人の感覚としては、論文と言うにはあまりにヒドい代物であって、評価に値しないと思う。歴史に関しては、ほんと俗説の寄せ集めだけで一冊本を書いちゃうような人がいて、私が良く使うホテルなんかにも、そこのお偉いさんが仕事の片手間に書いたような本が置いてあって微妙な気分になったりした記憶がある。表紙で読むまでもないと判断できる本なので読んだこともないが。閑話休題、件の論文は、ちと空自トップとしての資質を疑われるような稚拙なものであるというのは確かでしょう。そういえばこの人、空気読まずに「そんなの関係ねえ」発言した人でしたっけね。

2 に関しては、二つの点から田母神さんの行動はマズいわけね。一つは、内規に反して職務に関係ある論文を無届けで出している点。まあこれは見解の違いとかがあるからとりたてて大きな問題ではないけれど。

もう一つは、こっちのほうが重要なんだけれども、幕僚長という立場の人間が、政治的に微妙な内容の論文を出してしまうという軽率さですな。たとえ公務に関係ないところで出したものであっても、さすがに堂々と政府見解と反する見解を発表するのは、幕僚長として不適格と言われても仕方がない。

当人は「言論の自由はないのか」と息巻いているけれど、それはあまりにラジカルな考え方だと思う。こういうのは 1 か 0 かではなくて、「ある程度までは制限されてしかるべきである」というようなバランス感覚の上で論じないといけない。組織の統制という観点から、制服組幹部が(たとえ公務から離れた場であっても)言うべきではないことというのは存在する。「そういうことは退官してから好きなだけ言いなさい」というのが正しい。まあ実際、退官してからさらに好き勝手なことを言ってますなこの人。

3 に関しては、2 の最後とも関係しているのだけれども、確かに幕僚長という立場の人間が軽々しく政治的に微妙な発言をするのは文民統制上も好ましくない。でも、マスコミが言うようにその根幹を揺るがすほどのものかというと、そんな大したことじゃない。たまにこういう自重できない人がトップになってしまうという程度のこと。そもそも、文民統制の一番の核は何かと言うと、それは軍の人事権をしっかり文民が握っているということであって、今回、バカバカしいほど愚直に文民による人事権が機能したじゃないですか。いずれにしてもこれは、文民統制みたいな大鉈ふるうような話ではなくて、組織としての統率とか、綱紀粛正といったような話でしかない。

むしろ文民統制に危機があるとすれば、こんな下らないことに文民統制の大鉈を振りかざす連中がいることだと思う。特に今回、民主党がマスコミの幇間のような形でこの問題を騒ぎたてているのは困ったことで、万が一民主党が政権を取った時に、自衛隊員たちの人心をつなぎ止めておくことができるんですかねえ。今回のことで、やっぱり民主党には政権を任せられないという考えがさらに強くなったよ。

これをマスコミが公務員の綱紀粛正なんて話にせず、文民統制という自衛隊に固有の縛りで論じようとしてるのは、すんごく穿った見方をするならば、トップの指示に反した思想的活動をしている一部の地方公務員の方々を棚に上げたいからなのかなあ、とかそんな陰謀脳。

総合的に考えて、まあこんな人を空自のトップに持ってきた政府の責任ってのはあるとしても、おそろしく迅速に更迭した内閣の決断力はすごく評価できると思うんだけどねえ。

平成20年11月13日(木曜日)

今日

両陛下とスペイン国王夫妻、新型「お召し列車」で茨城へ - 行きと帰りの落差がひどい。

東北新幹線:七戸の新駅名は「七戸十和田駅」 - えーと……またですか。もともと七戸は乗り気だったし、この駅名になっちゃうんだろうなあ。JR 東がガン無視して七戸駅にしたら褒めてやる。

参考: Web東奥・ニュース 20001128 / 新駅名「十和田湖」めぐり争奪戦

「オープンソースへの貢献」って? - 「古くて新しい,また永遠のテーマでもあります」っていうけど、毎回同じような話にしかならないんだから論点は出尽くしている。毎度毎度総括する人がいないから話が発散して終わってしまってるだけで、誰かが統括した文章でも一本書けば、あとはそれを参照しろで済む話なんだがなあこんなの。

そろそろ、オープンソースへの貢献の垣根を低くした功績で OSSFJ にも貢献者賞くださいよいやマジで。冗談ですが。

夜中

某所で strncpy() が何でああいう仕様なのか話。

strncpy 関数は決して(BASIC あたりでいうところの) left 関数を実現するのが目的ではないのだが、困ったことに string.h のどこを見ても left の目的を実現する関数がない。どう見てもライブラリの缺陥ですありがとうございました。

デニスリッチーが UNIX のコマンドとかを実装するのに都合の良い関数だけを寄せ集めたのが C の標準関数の元になってて、そのうちのある部分は ANSI C の時に改められたけれども、文字列操作ライブラリに関しては良い意味でも悪い意味でも古き良き UNIX の思想がほとんどそのまま残っている。

strncpy() はもともとレコード形式ファイルなんかの固定長文字列フィールドを書き出すときに使うもので、固定長フィールドいっぱいの文字列なら最後の \0 は無くてもいいよね、というケチくさい思想に基づいている。

strncpy() は、フィールドへの書き込みにもフィールドからの読み込みにも使えるってのがミソ。フィールドへの書き込みは


でできるし、読み込みは 
void fetch_field(char *incorestr, const struct record *filerec)
{
   strncpy(incorestr, filerec->field, 8);
   incorestr[8] = '\0';
}
でできる。「入出力を一つの関数で済ませてやったぜヒャッホー」ってのがデニスリッチー的。構造化という観点からすれば、後者はわざわざ自分でヌルターミネートする必要がある時点で無理があるんだが、そういうことは考えない。

いずれにしても strncpy() は left 関数ではないのだが、あまりにも left 関数の代わりに使われることが多いので、のちの世には strlcpy() やら lstrcpyn() やらが生まれている訳です(まあどっちかというと left というよりはバッファオーバラン対策だけど……引数が文字列長ではなくてバッファ長だし)。しかしながら、何で誰も「真っ先に必要なのは strncpy() の亜流ではなくて left/mid/right 関数だろ!」って突っ込まないのかが謎ではある。

平成20年11月14日(金曜日)

査収物

ゲームプログラマになる前に覚えておきたい技術 / 平山 尚 - 重いよ。

More Exceptional C++ / ハーブ サッター,浜田 光之,浜田 真理

Boost / ビョルン・カールソン, 村上 雅章

ソラとアラシ(2) / 巣田 祐里子

ひだまりスケッチアルバム-TVアニメ公式ガイドブック- / 原作:蒼樹うめ,まんがタイムきらら編集部(編集)

今日

リニア「Bルート」要請 JR側、話し合う姿勢示す - きなくさくなってまいりました。

自民党リニア特命委員会の堀内光雄委員長は要望に対し、国交省は年内に新たな調査を指示すると説明。首都圏−中京圏間を自費で建設するJRの意向については「国家プロジェクトだから国も資金を出すのは当然。JRは国の方針に従ってもらう」と述べた。
なにこのボス猿。まあ東海も、独力建設をブチ上げた背景には国の動きが鈍いのを牽制するって意図もあったのであろうからこの辺は駆け引きの範疇ともいえるが。

ナギ様ビンテージ説。それはともかく、どうも名前からしてナギ様って実は男神じゃねえのって気がしますが「」的にはむしろご褒美です。

平成20年11月16日(日曜日)

今日

暇だったので川崎駅周辺散策。

ハンズで LED ナツメ球を買ってみた。

ヨドバシ。DSi は白黒とも潤沢。それはスルーしてシレンを買う。

帰ってマイメロ見たら事故ってた。「離れて観てね」がごっそり抜けてテレビ大阪のテストパターンに。

このところ TAS 動画を良く観てる。ちなみに私の弾いているベースは Tool-Assisted Bass です。K○T○K○が TAV なのは公然の秘密な。

平成20年11月17日(月曜日)

今日

神力レベルアップによるオオヌサの進化予想:

レベル 1: ケガレを祓える
レベル 2: 光る
レベル 3: 音が鳴る←イマココ
レベル 5: 杖の先にえんぴつが付く
レベル 6: 杖の頭に消しゴムが付く
レベル 8: 消臭抗菌加工になる
レベル 11: 目覚まし時計が付く
レベル 15: 釣り竿になる
レベル 25: 公衆電話がタダでかけられるようになる
レベル 30: 瞬間接着剤の剥がし液が出るようになる
レベル 34: ポケベル機能が付く
レベル 40: 口内炎が直せる
レベル 70: カピルス発射
レベル 110: ワンセグ受信可能に
レベル 200: 監督の域に達する
レベル 400: サイコロの目を操れるようになる
レベル 500: ブルーレイへの録画が可能に
レベル 1000: オオヌサが自我に目覚めて英語を話し出す
レベル 1100: 飛行可能に
レベル 1280: βマックス再生可能に
レベル 1500: 敵に向かってビームを発射する。相手は死ぬ
レベル 1800: 敵にお話を聞いてもらう。相手は死ぬ
レベル 2000: 敵に向かって雷を落とす。相手は死ぬ
レベル 3000: 日米通算 3000 本安打
レベル 5000: 敵に向かって隕石を落とす。相手は死ぬ。8時だョ!全員集合の「盆回り」 BGM がかかる
レベル 6000: ワープ 9 で飛行可能に
レベル 7000: <s> ふともも </s>天の岩戸をこじ開けられる
レベル 8000: 時を止められる
レベル 9000: そして時は動き出す
レベル 10000: タイムトラベル可能に
レベル 1000000: 天地創造

平成20年11月19日(水曜日)

今日

とりあえずフルバージョンできたが、もう少し直す。

嫁力レベルアップによるつぐみの進化予想:

レベル 1: おひたしが作れる
レベル 2: 卵焼きが作れる
レベル 3: おひたし入り卵焼きが作れる←いまここ
レベル 5: スカート下ジャージ自体が恥ずかしいと悟る
レベル 6: 粉吹き芋が作れる
レベル 8: 煮魚に挑戦して失敗する
レベル 10: 肉じゃがが作れる
レベル 12: カレー作りに凝って一日かけるようになる
レベル 14: 学校帰りに制服で買い物するのが日課に
レベル 16: 16 歳になる
レベル 20: レパートリーが 20 を突破
レベル 23: 香辛料を揃え出す
レベル 25: フルタイム C カップになる
レベル 28: カレーを圧力釜で手軽に作ることを覚える
レベル 30: レパートリーが 30 を突破
レベル 34: 菓子作り教室に通いだす
レベル 43: エプロン付けたまま、うっかり切らした醤油を買いに行く
レベル 50: レパートリーが 50 を突破
レベル 62: 米のとぎ汁を有効活用し出す
レベル 83: 思わず砥石を衝動買い
レベル 92: 裁縫教室に通いだす
レベル 100: レパートリーが 100 を突破
レベル 200: 監督の域に達する
レベル 300: やっとビデオの予約ができるようになる
レベル 400: 天ぷらを極めるが、面倒なので敬遠するように
レベル 500: 外食すると「あー、ご飯作らないの楽でいいわ」とか言い出す
レベル 600: 仁の留守に上がり込んでご飯を作る。玄関に人の気配がしたので、
            台所の暖簾越しに
            「ねえ、ご飯にする? お風呂にする? それともア・タ・シ?」
            と言ったら、帰ってきたのはナギ様だった。おいしく召し上がられた。
            ナギ様の嫁になる決心をする。

フォントについての質問です - ワロタ。これって釣りなのかなあ。質問者も質問者なら、回答者も回答者だなあ。きもいなあ。

「彼氏が Windows 使ってた。別れたい……」以下略。

書評。どうもその、陳腐で大仰なレトリックを使われるとその本自体を読む気が失せる。納税に匹敵するとか。俺がひねくれてるのかなあ。

うんまあそんなすごい本なら読む必要はないんだよ。放っておいてもその考えるところが人口に膾炙してくる。逆に人々の間に浸透してこないならその程度の内容だってことで、やっぱり読む必要はない。

しかし書評って難しいよなあ。面白い本の感想なんて「面白かった」以上のことをかけるもんではない。世の中の書評は、往々にして書評の姿をした自分語りになっていたりすることがあるけれど、そういうのってのはやっぱり、「面白かった」以上に書くことがないのに、無理して何か書こうとしてるからそうなってしまうんだろうなあ。自分語りでもなんでも面白ければそれでいいんだが、そういうのを面白く読ませるだけの芸達者はなかなかいないねえ。

平成20年11月20日(木曜日)

今日

errno == EINVAL - なんか次の原則に反するので単に仕様のバグのような気もしますが:

The value of errno should only be examined when it is indicated to be valid by a function's return value.
(2.3 Error Numbers / The Open Group Base Specifications Issue 6)
それはともかく、仕様パラノイアとしては mbrtowc() する前に errno = 0 しといた方がいいでしょう:
No function in this volume of IEEE Std 1003.1-2001 shall set errno to zero.
(同)
つまり mbrtowc() が正常終了した場合に errno をゼロクリアすることはないから、呼び出し前に errno が EINVAL だと正常なのか異常なのか区別できない。まあやっぱり RETURN VALUE のバグでしょうこれ。ライブラリ作る側としては -1 を返しておくのが無難。

ところで、より厳密にいえば、上の No function 云々ってのは「(その関数を実行した副作用として) errno を 0 に設定するような関数は一つもない」ということなので、これは一つには「正常終了だからといって errno が 0 であると期待してはいけない」ということを暗に言っている。しかし、正常系で errno を書き換えちゃいけないとはどこにも書いてないので(見落としがあったらごめん)、ライブラリ実装者のポリシで正常終了時に errno をゼロクリアすることは禁止されてない。それどころか、たとえば内部で別の標準関数を呼び出した副作用で errno が変化したとしても、元の値を復元する必要すらない。もちろん例外を除く(確か errno には影響しないと明記された関数があったはず)。まあリーズナブルな仕様ですな。

ちなみに、E で始まるエラーコードが具体的にどんな値になるのかはこれっぽっちも書かれてないのだが(int のリテラルに展開されることだけが明記されてる)、上の文があるので 0 でないことだけは保証されている。この辺は仕様策定者の微妙な乙女心が作用していると思われる。

soda さんから、errno = 0 しておかないと困る例として strtol(3) の EXAMPLES を教えて貰いました:


どうみてもバグの温床ですありがとうございました。これは要するに、上の No function うんぬんっていう縛りがあるので、呼び出し元で errno = 0 しとかなければならないということでしょうねえ。なんでそこまで標準関数の中で errno に 0 をセットするのを拒むのか謎ではある。 

いずれにしても、ダメなインターフェースのパターンの一つだよな。新しく仕様を決めるなら、


とかすべきだろうな。あるいはケチるにしても 
SYNOPSIS
  char *strtoi(int *rval, const char *numstr, int base);
  char *strtol(long *rval, const char *numstr, int base);
  ...
RETURNS
  these functions return NULL and set errno if error is occured,
  otherwise the pointer to the character just after converted digits.
ならば多少マシ。関数の数は増えるけど。

でもさあ、int と long は一般的には一致しないので、strtol で int 値を正しく読みたいなら、


とか書かなきゃいけなくて、すごくマヌケ。それに、int と long が同じ範囲だと、コンパイラが「無意味な比較」っていうような警告出すよなこのコード。いずれにしても strtoi() は必要だろ JK。 

閑話休題、上の strtol() はすごく特殊な例だけど、こういう「正常値と区別がつかない戻り値でも errno が有効なケース」というのもあるので、ひょっとすると mbrtowc() の例も仕様書のバグではなくて nozaki さんの解釈が正しいんだったりして。でも「エラーなら (size_t)-1 を返す」のほうが合理的だよなあ。いずれにしても Austin Group ML で訊けばいいんだけど。