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

> > (盲目的に) strcpy を strlcpy にするという方法では駄目だと主張していま
> > す.
> 
> それは、いいんじゃないですか。「盲目的」なんて誰も言ってないし。

そのお言葉はもう少し早く頂きたかったかも…. 

In article <c17e5u$2eji$1@news2.rim.or.jp>
        dohzono@hf.rim.or.jp (Kazuo Fox DOHZONO) writes:

| # 先の記事を読んで何も考えずに strcpy を strlcpy にする人がいるとい
| # けないと思って色々書いてみました. 

                              ○

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

はい. これについては共通の見解だと思っていました↓. 

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

| 最初はきついかもしれませんが、人間鍛えられます。

                              ○

> 私は、strlcpy() の方が、プログラマの負担が減ると主張しています。
> strcpy() なら自分の仕事になる所を、strlcpy() なら、代りにに
> コンピュータがやるわけでしょ。コンピュータが仕事をした分、人
> 間の仕事が減っています。
> 
> 単純な引算ですよね。

「既にチェックされたものに対する strl?cpy」の話なので, strlcpy の方は
加算のはずです.

# その加算分のコストを払ってでも, という話をされていたのでは?

                              ○

> > # 直接フォローはしていませんが, 「(書き替えその他が) 簡単である」とい
> > # う主張は認められないということでもあります.
> 
> 具体的に難しい例を出して下さい。

すぐに思いつくのは最近やった仕事の変形ですが.

unsigned
txbuf_set (char *txbuf)
{
  unsigned wi = 0;
  …;
  {
    foo_t *foop;
    if ((foop = foo_get ()) != NULL)
      {
        strcpy (&txbuf[wi], foop->name);
        wi += foop->nlen;
      }
  }
  …;
  return wi;
}

txbuf の具体的な大きさは (自動的に算出されているので) 私は知りませんし,
strlcpy を使うには残りバイト数も数えなければなりませんし, rewind 要件
も洗い出さなければなりません. 

strcpy → strlcpy の書き替えとは違いますが, やっちゃいそうな間違いと言
うと

void
foo (char *d, const char *s)
{
  …;
  if (strlcpy (d, s, sizeof d) == sizeof d)
    むにゃむにゃ; 
  …;
}

なんていうのも思いつきます. 

# これもいつか来た道だったり. 

                              ○

> > Samba の例が出たことでその方法では駄目だということが立証されているので
> > はありませんか?
> 
> いいえ。Samba の方法では、うまくないですが、うまくコンピュー
> タに仕事を任せる方法、つまり、コンパイラの静的な型チェックが
> 働く方法にすれば良かったということです。基本的に人間の仕事を
> コンピュータにやらせるという方向性はよかったけれど、方法が今
> 一つだったと。

面白いことに secure であるとされる qmail は, よくある string 型のよう
に文字列を扱っているにも関わらず, 型チェックの恩恵の一部を放棄している
ように見えます (traditional C な関数宣言).

# ひょっとしてディストリビュート時に unprotoize 通してる?

stralloccopy なんていうのも使われていたと思いますが, strcpy そっくりな
関数もあったはずです. 

                              ○

> >> それで、どういう方針なら、「strlcpy() を使うな、strcpy() を
> >> 使え」と出てくるののですか？
> > 
> > 私が作った仕掛けを他の人も必ず使うという保証はあるの? という問いに対す
> > る答えだったつもりです. 
> 
> この部分の意味がよくわかりません。

私の理解では以下のような流れです. 

In article <c1fl9o$dl5$1@news2.rim.or.jp>
        dohzono@hf.rim.or.jp (Kazuo Fox DOHZONO) writes:

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

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

> そのプログラムを明日誰かが直したとして、その直した誰かがバッ
> ファ・オーバーフローのバグを入れないという保証は、できないでしょ。
> バグを入れた人の責任だと言うのは簡単

In article <c27vng$arp$1@news2.rim.or.jp>
        dohzono@hf.rim.or.jp (Kazuo Fox DOHZONO) writes:

> 責任は書かせた人にもあるわけです. 「このソフトウェアはどのような設計思
> 想に基づいていて, それがどのように実装されているのか」というレビューま
> で普通やるじゃないですか.

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

> 「普通」というのは、どういう状況でしょうか。もう少し詳しく教
> えてください。大学だと何が普通なのかが実はよく分からないとい
> う話があります。

In article <c3sj8v$21rk$1@news2.rim.or.jp>
        dohzono@hf.rim.or.jp (Kazuo Fox DOHZONO) writes:

> 手を入れるソフトウェアに上の「」のような文書がない場合, それを作成する
> ところから始まります. で, その設計方針が「ちょっとなぁ」というものであっ
> た場合は, ソフトウェア全体を作り直すこともあるわけです. 
> 
> 次に実際のソフトウェアとつき合わせながら, 手を入れることによって及ぶ影
> 響の範囲とテストの条件などを洗い出していきます (で, 見積りを出したり). 
> 
> …なんてことを会社ではやるわけですが, 文書に起こすかどうかは別として普
> 通個人でソフトウェアを改変する場合でもやっていることだと思います (私は
> 学生時代からそうしていたけどなぁ). 以前何処かでコーディングスタイルの
> 話が出た時に「基本的に元のスタイルに合わせる」という話になっていたと思
> いますが, それのもうちょっと上のレイヤでもそうする, という感じ.

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

> それで、どういう方針なら、「strlcpy() を使うな、strcpy() を
> 使え」と出てくるののですか？

In article <c4q1ov$1cgi$1@news2.rim.or.jp>
        dohzono@hf.rim.or.jp (Kazuo Fox DOHZONO) writes:

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