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

> strlcpy() は、バッファ・オーバーフローを起さないという目的で使うもの
> です。strlcpy() を使ったからといって、間違ったプログラムが「正しく」
> 動作するようになるわけではありません。

確認しておきますが, strlcpy によってバッファオーバーフローが「起こらな
くなる」ケースでは間違ったプログラムを前提としているわけであり, それは 
strlcpy を使っても依然として間違ったプログラムであることに変わりありま
せん.

人的ミスならそういうものを持ち込ませない, 或は, 万が一持ち込まれてもテ
スト等で発覚するような設計にするべきで (Java を使うってのもこの辺に入っ
てくるわけでしょう), 「持ち込まれても strlcpy で」っていうのは問題に対
処するベクトルがずれている気がするんです. 新人君に教える心得としても甚
だ不適当なものでしょう.

> テストでは、バッファ・オーバーフローは見つかりにくいんじゃな
> いですか。

そういうのも「不適当なバッファを適当にとること (たとえば, FILE * と無
関係な場所で BUFSIZ を使ってみたりとか)」の弊害でしょう. 過不足なく 
(過…なく, がミソ) 確保するようにして, 仕様上の最大長やその数倍程度を
入れてみれば大抵発覚するのではないですか. 私の経験上はそんな感じ.

…とはいえやっぱりテストに頼るような設計にはしないなぁ. 今やってる仕事
で grep したら strcpy が 200 個くらい出てきましたけど, バッファ長とか
はプログラムで算出させてチェックは上位層でやってるし. もちろんテストも
やってますけど.

で, これを全部 strlcpy にして一々チェックを入れて「どういうアクション
を起こすか (起こりもしないのに)」と考えるのは, 馬鹿げてるでしょ?

> それより、"foobar" が "foo" につめられて動作がおかしいいう方が見つか
> りやすいんじゃないかなあ。

あるキーで登録された値が別のどんなキーでも読めないことをテストで保証す
るのは到底不可能ですし, リリース後におかしな動作が発覚するのでは遅いと
いう場合も多々あるわけです. というか仕事でそれはマズ過ぎ.

# デバッグ方法にも疎くて「動きません」と泣きついてくるならいざしらず, 
# ホントにそうやって隠蔽しちゃう新人君も世の中にはいる, らしい.

また, 仕様にないコードはテストケースから洩れている可能性が高いわけです
から, その部分は未テストのままリリースされることになりかねません. その
後のコードが正しいことはどうやって保証するのでしょうか. strlcpy 判定後
のコードを書くくらいですから, プログラマは当然その辺りに思い当たってい
るはずです. そんなことが予めわかっているのなら, それは仕様に含まれ, テ
スト項目に入るべきものではないのでしょうか.

# ちまちましたテスト項目を増やさないためにも設計が肝要なわけですが.

> >   if (strlcpy (buf, src, sizeof buf) == sizeof buf)
> >     /* さて, どうするの? */; 
> > 間違いやすい人間に毎度毎度チェックさせるの? という話にもなります.
> 
> それは、同感です。まあ、マクロ一発という話もありますけど。

ないない. 

> #define    Strlcpy(dst, src, size) if( (strlcpy((dst),(src),(size))>=(size)) ) \
>                                error("buffer over flow.")

この error とやらはその時その時の状況に応じて事象の巻き戻しから何から
面倒をみてくれる魔法の仕組みなんですか? 

# 戻り値に対する不等号も気持ち悪いなぁ.