web archive

Unsigned character
http://www.dwheeler.com/blog/2006/03/28/#unsigned-char
C に 関連したところを ちょっと 訳してみた。

技術的な 基礎から 始めましょう。 C には char 型が 含まれていて、通常 8 ビット文字を 格納し 使用します。 国際化した プログラムの 多くは、テキストに UTF-8 を 使って エンコードしているので、ユーザが 見る 文字は char の 値の 連続 (sequence) として 格納されています。 しかし、国際化した プログラムでさえ しばしば テキストが ある 1つの char 型で 格納されています。

C standard には、はっきりと char を signed あるいは unsigned に することが できると 述べてあります (信じられませんか? では、ISO/IEC 9899:1999、セクション 6.2.5、パラグラフ 15 の 2番目の センテンスを 見るように、そう そこです)。 多くの platform (たとえば Linux に 代表される) で、char 型は signed に なっています。 問題は、ソフトウェアの 開発者が char 型が unsigned であることを、しばしば まちがって 考えているか、signed 文字の 分岐 (ramification) を わかっていないことです。 この 思い違いは、時とともに より 一般的に なっています。 なぜなら、他の C に 似た 多くの 言語 (Java や C# のような) が、必要上 unsigned と 定義しているか、あるいは、いくらかは たいしたことでは ないと しているからです。 最悪の 場合、この 思い違いは まっすぐ セキュリティでの 弱点へと 導かれます。

singed 文字を ともなう システムでは、さまざまな 種類の 奇妙な 事態を、発生させることが できます。 例えば、文字の 0xFF は、 C や C++ の 拡張された ルールにより、それと 等しいものとして 整数の -1 に 一致 (match) するでしょう。 そして、このことは すぐに セキュリティの 欠陥を つくりだすことが できます。 なぜなら、-1 は ふつう、多くの 開発者が char では 起こらないと 推定している、番兵の 値だからです。 Sendmail の よく知られた セキュリティの 欠陥の 1つは、まさに この問題から 起こっています (詳細は、US-CERT #897604 と Michal Zalewski による 投稿を 参照)。

Securing Mycrosoft Windows for Home and small Business Users
http://www.dwheeler.com/essays/securing-windows.html
同じく、David A. Wheeler による 記事。 こちらは Windows の ユーザに 向けた 解説です。


(追記) 訳文を 少しだけ 訂正。