ねことくまとへび

【東北楽天 vs 埼玉西武 第13回戦】
（2009年7月28日：岩手県営野球場）
　
埼玉西武  1 0 0  0 0 0  0 0 0  1
東北楽天  0 1 3  0 0 0  0 1 x  5
　
[勝] 岩隈　 7勝5敗0Ｓ
[敗] 石井一 4勝7敗0Ｓ
　
[本塁打]
  3回裏 山崎武 21号 ３ラン （石井一）
  8回裏 山崎武 22号 ソロ　 （藤田）

後半戦の開幕戦。

初回にライオンズが制球の定まらない岩隈を攻めて1点を先制しますが、その後はゲッツーを繰り返すうちに立ち直られてしまいました。

対するライオンズ先発の石井一はなかなかいい立ち上がりを見せたものの、3回に自らのエラーでピンチを招き、山崎武に一発食らって勝ち越しを許しました。ホームランは仕方がないにしても、溜めたランナーは余計でした。

http://japan.cnet.com/news/sec/story/0,2000056024,20397505,00.htm

昨日の続きです。というか、そもそもCNET Japanの記事のほうが先だったようですが。

ニュース記事自体から得られる情報は昨日と大して変わりませんが、Microsoftのブログへのリンクがあったので辿ってみたところ、面白い記述を見つけました。

I contend that this would be very difficult to spot in a code review, and is not picked up by the C/C++ compiler owing to the (void*) cast. If the cast is removed, the compiler issues an error like this:

C2664: '<function>' : cannot convert parameter 1 from 'BYTE **' to 'BYTE *'

The Security Development Lifecycle : ATL, MS09-035 and the SDL

茶吹いた。void *へのキャストはコンパイルエラーを消すためだけに付けられたものようです。「消す」というよりは「ごまかしてなんとかコンパイルを通す」という感じかな。

おそらく作業者は最初にこう書いたのでしょう。

hr = pStream->Read(&pbArray, (ULONG)cbSize, NULL);

しかし、コンパイルが通りませんでした。そして、コンパイラが見つけた「引数の型が違う」というエラーを消すために、正しい型の引数を持ってくる *1 のではなく、単にコンパイラを黙らせる *2 ことを選んだのですから、これはtypoによるセキュリティホールではありません。もっと別の次元のミスであり、このミスに関しては防ぐことができたはずです。

「プログラムは意図したとおりではなく書いたとおりに動く」という格言がありますが、まさしくそれを実証しているソースコードですね。コンパイルエラーを消すために意図とは全く違うコードになってしまった。

もしこのミスをしたのが新人だったら、噛んで含めるようによく言い聞かせることです。きっと彼（彼女）は二度と同じ間違いはしなくなるでしょう。

もしこのミスをしたのが30歳を超えていたら、すぐに別の仕事を紹介してあげることです。きっと彼（彼女）は「コンパイルが通るコードを書く」ことが仕事だと勘違いしており、これから先も周りの技術者に迷惑をかけ続けることでしょうから。

http://japan.internet.com/webtech/20090731/12.html

プログラミングの経験のない方は、「たった1文字間違えただけか」という印象を抱くかもしれませんが、間違えた場所をよく見てみると、わりととんでもない間違いをしています。

具体的には

hr = pStream->Read((void*)pbArray, (ULONG)cbSize, NULL);

と書かれるべきコードが、

hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);

と誤って書かれていた。

Microsoft の『ATL』のコードに不具合、原因は「&」

pStreamがどんなオブジェクトなのか、Read()がどんなメンバ関数なのかははっきりは分かりませんが、おそらくpStreamの入力ストリームからcbSizeのサイズ分だけ読み取り、結果をpbArrayの指し示す先の配列に書き込むといった処理だと思います。

各変数にはプリフィックスがついていますが、悪名高きシステムハンガリアンではなく、アプリケーションハンガリアンでしょう。pbArrayがboolへのポインタだとは思えないので。おそらくcbはCount of Byteで、pbはPointer of Byteといったところでしょうか。

ハンガリアン記法を使うこと自体は問題ありません。問題は、せっかくプリフィックスをつけたというのに、それを全く活かせていないことです。

書き込む先のアドレスを渡さなければいけない場所で、なぜpbArrayそのものではなく、pbArrayのアドレスを渡すようなコードを書いてしまったのか。作業者は「pb」の文字が目に入らなかったのか。まぁ、おそらく作業者が疲れていたんでしょうけど、せっかくのプリフィックスを妥当性チェックのために使用しないのであれば、タイピング数を増やすだけのルールはやめてしまえばいいのにと思います。

というか、こういうミスが出てくるとハンガリアン記法不要論に勢いを与えてしまうんだよなぁ *1 。困ったものです。

賢押杯2009 *1 のエントリー開始の日が近づいてきました。今年も参加させていただこうと思いますので、スタッフの皆さん、参加者の皆さん、どうぞよろしくお願いします。

ところで、そのエントリーに際してまだ迷っていることが一つあります。それは登録の際の名前です。

廃人になりきれていなかったQMA1の頃を除くと、QMA2～QM5、そしてAn×An1はすべて「ちぃといつ」というCNでプレイしており、過去の賢押杯のエントリーの際も迷うことなくその名前で申し込むことができました。

しかし、現在稼動中の作品については、QMA6が「シアンフロこ」でAn×An2が「パグリアルよ」です。困りました。いや、CNを別々にしてしまった自分が悪いんですけど。

そんなこんなで色々な方に相談したのですが、「シアンフロこ」でAn×An界隈にどれだけ通じるか、「パグリアルよ」でQMA界隈にどれだけ通じるかということを考えれば、パグリアルよのほうがいいんじゃないか、という指摘があったので、パグリアルよで参加しようと思います。

ところで、今急に思い出したんですけど、前回の賢押杯の名札は持ちキャラの素敵な絵が描かれていたんですよね。

……平原より山脈のほうがいいよね、うん。じゃあシアンフロこにします。

話題沸騰のスペースインベーダーインフィニティジーンを購入してみました。

http://www.youtube.com/watch?v=ShO9rtyIX-0

詳細なレポートを書けるほどやりこんではいませんが、久々に大当たりを引けたような気がします。しばらくは楽しめそうです。