新城＠筑波大学情報です。こんにちは。

In article <c2esvq$2ta5$1@nsvn01.zaq.ne.jp>
        shirai@unixusers.net (Takashi SHIRAI) writes:
> >いいえ。トータルで考えれば、バグ入りプログラムからバグを見つ
> >けるより、最初からバグがないプログラムを書く方が楽（得）です。
> 　この「最初からバグがない」という点が過信に繋がり兼ねないと
> 思うので、私はこの考えには危険が伴うと思います。

strcpy() と strlcpy() の話と「最初からバグを入れない」という
話は別の話です。strcpy() を単純に strlcpy() 変えてもバグは残
ります。つまり、分類（Ａ）（Ｂ）両方の話です。

> 　この過ちを侵している代表例が Samba ですね。こいつは一つも
> strcpy() を使わないように工夫していますが、長さ指定ミスによ
> る buffer overflow は過去幾つも発見されています。

具体的にどんなバグだったのでしょうか。これを検証すると面白い
データが得られると思います。

> 　strlcpy() 自体は有用な関数だと思いますが、それを使うことが
> 即「セキュリティ上の弱点に繋がる間違い」を完全に回避出来ると
> する思い込みは、却って危険だと思います。

同感です。

> 　長さの指定を programmer に委ねている時点で fgets() も同じ
> ことだと思います。私は fgets() の代わりに asprintf() みたい
> な仕組みを実装することが多いですね。

asprintf() って何ですか？

strcpy()/strlcpy() のスタイルよりも snprintf() のスタイルの
方がよいとは思います。

> ＃　私は library bug に何度も悩まされた挙げ句、library 関数
> ＃の互換品を自作する癖がついちゃいましたが :-)

具体的に何というライブラリでしょうか。さしつかえなければ教え
て下さい。

「最初からバグが入らないようにする」というのは、雑誌 
Software Design の１月号の Bart Eisenberg の Pacific
Connection に出ていたと思います。

In article <c2gqsb$q3u$1@dnknews.denken.or.jp>
        TAKENAKA Kiyoshi <takenaka@criepi.denken.or.jp> writes:
>  >人間がやることではないということには同意します。コンパイラな
>  >ど言語処理系でやるべき仕事でしょう。でもコンパイラがしょぼい
>  >と人間がやるしかありません。
> コンパイラがしょぼい場合は、人間ではなく、プログラムにやらせれば
> よいでしょう。

プログラムにやらせるとして、具体的にどうすればいいんですか？

コンパイル時に働くプログラムがコンパイラとして、実行時に何か
やればいいということですかね。実行時にライブラリ関数でやると
いうことでもいいですが、その方法の１つが strcpy() じゃなくて
strlcpy() ではあるんですけれど。

コンパイラでやる方法にも、StackGuard とか Fail-safe C とかい
ろいろあります。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼