MSDN の ReadConsole の記述に不満あり

先日来、GnuPG の挙動を調査していて、Win32API の ReadConsole 関数の挙動に苦しめられている。
2008年10月1日現在で、MSDN の ReadConsole 関数の解説にも納得のいかないところがあるので、ここでツッコミを入れておく。

MSDN の ReadConsole の説明 http://msdn.microsoft.com/ja-jp/library/cc429657.aspx には


BOOL ReadConsole(
HANDLE hConsoleInput, // コンソール入力バッファのハンドル
LPVOID lpBuffer, // データを受け取るバッファのアドレス
DWORD nNumberOfCharsToRead, // 読み取る文字数
LPDWORD lpNumberOfCharsRead, // 実際に読み取った文字数のアドレス
LPVOID lpReserved // 予約済み
);

パラメータ

hConsoleInput
コンソール入力バッファのハンドルを指定します。このハンドルには、GENERIC_READ アクセス権が必要です。
lpBuffer
コンソール入力バッファから読み取ったデータを受け取るバッファへのポインタを指定します。
nNumberOfCharsToRead
読み取る文字数を指定します。この関数は 2 バイトの Unicode 文字、1 バイトの ANSI 文字のどちらでも読み取ることができるため、lpBuffer が指すバッファのサイズは少なくとも nNumberOfCharsToRead * sizeof(TCHAR) にしてください。
lpNumberOfCharsRead
実際に読み取った文字数を受け取る 32 ビット変数へのポインタを指定します。
lpReserved
予約済み。必ず NULL を指定してください。


このような記載がある。

問題は、引数 nNumberOfCharsToRead の説明。
「lpBuffer が指すバッファのサイズは少なくとも nNumberOfCharsToRead * sizeof(TCHAR) にしてください。」と書いてあるが、実際の ReadConsole 関数は、Unicode 対応ではなく ANSI 対応でコンパイルした場合で、入力文字が日本語などのダブルバイト文字の場合、nNumberOfCharsToRead に 1 を指定してあったとしても、lpBuffer には2バイト分の文字が格納されてしまう。nNumberOfCharsToRead * sizeof(TCHAR) ではバッファが足りなくなるのだ。
ドキュメントと関数の実際の挙動が違う

私の手元の Windows XP Pro SP2 だけに固有の現象なのか、WinNT系全般の現象なのか、Windows全般の現象なのか、そのあたりはまだしっかりとは検証できていない。しかしこれはバッファオーバーフローをひき起こしかねない問題なので、Windows XP Pro SP2 で見られる現象というだけで、十分に致命的だ。

なぜ、このようなつまらないことを敢えてここに書いてしまったかというと、GnuPG Project にパッチを送るために説明を書こうとして、ReadConsole 文の挙動を説明するのに MSDN を引用しようとしたのだが、こういった事実と異なる記事になっていたために、にっちもさっちもいかなくなって、思いっきり不機嫌になってしまったからである。

ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 0

この記事へのコメント

この記事へのトラックバック