堂園です. 

なんか色々話が進んでいるようですが. 

In article <YAS.04Mar7023326@kirk.is.tsukuba.ac.jp>
        yas@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> > > （Ａ）セキュリティ上の弱点に繋がる間違い
> > > （Ｂ）セキュリティ上の弱点には繋がらない間違い
> > これをプログラマが区別しないといけないのかなぁ (区別するとしたらどう考
> > えたら／捉えたらいいのだろう), というのがここ数年私が考えているテーマ
> > だったり.
> 
> 私は（Ａ）（Ｂ）を区別する必要があると思います。両方無くなれ
> ばそれに越したことはないけれど、潰すならまず優先的に（Ａ）か
> ら潰せという意味です。

そういう設計指針 (プログラマに個別に負担させる) であれば, C 言語を選ん
だ時点で間違っていると思います. C を使うのであれば, 別の設計指針を採択
すべきだと思うし.

> > 「strcpy で出てくるようなセキュリティ上の問題」は出てこない. しかし, 
> > 個別に一々プログラマに担わせていたのでは駄目なんじゃないですか? 
> 
> いいえ。トータルで考えれば、バグ入りプログラムからバグを見つ
> けるより、最初からバグがないプログラムを書く方が楽（得）です。

そういう方針で作れるプログラムってとてもとても小さなものに限られちゃう
と思います. 見通しも悪くなるし. 

> > 責任は書かせた人にもあるわけです. 「このソフトウェアはどのような設計思
> > 想に基づいていて, それがどのように実装されているのか」というレビューま
> > で普通やるじゃないですか.
> 
> 「普通」というのは、どういう状況でしょうか。もう少し詳しく教
> えてください。大学だと何が普通なのかが実はよく分からないとい
> う話があります。

手を入れるソフトウェアに上の「」のような文書がない場合, それを作成する
ところから始まります. で, その設計方針が「ちょっとなぁ」というものであっ
た場合は, ソフトウェア全体を作り直すこともあるわけです. 

次に実際のソフトウェアとつき合わせながら, 手を入れることによって及ぶ影
響の範囲とテストの条件などを洗い出していきます (で, 見積りを出したり). 

…なんてことを会社ではやるわけですが, 文書に起こすかどうかは別として普
通個人でソフトウェアを改変する場合でもやっていることだと思います (私は
学生時代からそうしていたけどなぁ). 以前何処かでコーディングスタイルの
話が出た時に「基本的に元のスタイルに合わせる」という話になっていたと思
いますが, それのもうちょっと上のレイヤでもそうする, という感じ.

> 「そんなこともあろうかと」って、言ってみたいセリフでしょ。

strlcpy が働いた時点で言える台詞ではありませんよね. それは正しくないソ
フトウェアが, 正しくない動作をした時なのですから.

                              ○

「正しさよりもセキュリティに重点を置く」という指針からは「何もしないプ
ログラム」が導かれちゃう, という話についてはどうお考えですか?