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

> 最初から私はＣ言語を使うなと書いています。

非力な MPU や特殊なものになると選択肢がそれくらいしか無い場合もありま
す. 

# 今社内でやってるのに Pentium でアセンブラってのがあるけど :-p

> > > > 責任は書かせた人にもあるわけです. 「このソフトウェアはどのような設計思
> > > > 想に基づいていて, それがどのように実装されているのか」というレビューま
> > > > で普通やるじゃないですか.
> > 手を入れるソフトウェアに上の「」のような文書がない場合, それを作成する
> > ところから始まります. で, その設計方針が「ちょっとなぁ」というものであっ
> > た場合は, ソフトウェア全体を作り直すこともあるわけです. 
> > 
> > 次に実際のソフトウェアとつき合わせながら, 手を入れることによって及ぶ影
> > 響の範囲とテストの条件などを洗い出していきます (で, 見積りを出したり). 
> 
> それで、どういう方針なら、「strlcpy() を使うな、strcpy() を
> 使え」と出てくるののですか？

私が作った仕掛けを他の人も必ず使うという保証はあるの? という問いに対す
る答えだったつもりです. 

> > > 「そんなこともあろうかと」って、言ってみたいセリフでしょ。
> > strlcpy が働いた時点で言える台詞ではありませんよね. それは正しくないソ
> > フトウェアが, 正しくない動作をした時なのですから.
> 
> 人間は常に間違うということを認めようという話をしているんだけ
> ど。人間は正しいく動作するソフトウェアを書いたつもりなんだけ
> ど必ず間違えます。それで、間違いをしないようにプログラムを書
> くのはもちろん大事です。でも、間違ったとしても、安全なプログ
> ラムを書くというのも大事です。そういう話をしています。

# 人命に関わるような「間違い」もある訳ですが, それはさておき. 

(盲目的に) strcpy を strlcpy にするという方法では駄目だと主張していま
す.

指定するパラメータも増え, rewind の方法も考えなければならない (仕様上
あり得ない状況について考えなければならない), と書きました. プログラミ
ングにおける, 間違い易い人間への負担が増える仕組みは (少なくとも, 私の
経験上は) うまくいきません. 本来考えなければならない部分からプログラマ
の注意を逸すような仕組みは, 別の問題を作り込むことにもなりかねません.

# 直接フォローはしていませんが, 「(書き替えその他が) 簡単である」とい
# う主張は認められないということでもあります.

Samba の例が出たことでその方法では駄目だということが立証されているので
はありませんか?