アカウント名:
パスワード:
Code-auditing by AT コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったティップスや方法に関して教えていただけるとありがたいです。仕上がったばかりのコードの場合は、まずどこを探りますか?。成熟したコードの場合は?。
Theo: 一番のティップスは、今よりももっと良いプログラマーになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べること、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だよ。これを読む人の中の果たして何人が、libcの全ての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。(どういうことかって言うと、今までソースツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていたし、もし一文字足してしてヌル文字で終端するだけのつもりなら、それはやっぱりいい具合じゃないってこと)
APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらある。それを僕らが見つけた時には、すでに多くのプログラマーがその間違ったやり方でプログラムを書いていた…。
---------- ssh使わない日はないし、BSDが押され気味なのはちょっと悔しいし、どれくらい直されるのかを見てみたいと言う恐いもの見たさでやってみました。
訳に迷っているところばかりですけれど、特に一番最後
lots of programmers had followed the instructions incorrectly...
lots of programmers had followed the incorrect instructions...
strncat()とstrncpy()のくだりも、manは読みましたが、
they copied a character extra
strcat/strcpy はバッファオーバーフローの元凶だということで strncat/strncpy に置き換えるのだが,それの使い方がなってないと言うことでしょうね. strncat/strncpy は,第3引数に「コピーする文字列のバイト数」を渡すけれど,これには終端のヌル文字を含まないので,うっかりそれを忘れてバッファの残りサイズをそのまま渡すと,
ということになります.はっきりいってわかりにくいし,使いにくいので,その代わりに strlcat/strlcpy があるのですが.
numaさん、こんにちは。フォロー下さいましてどうもありがとうございます。うーん、じぇんじぇん違うですね。
仕事が退けたらnumaさんにいただいたのをもとにググって、該当部分を書き直してみます。一回で済まずに、お手間をとらせることになってごめんなさい > yhさん。
私などより、よほどましに訳せて、ここらの文脈に明るい方がいらっしゃると思いますので助け舟お願いします > お読みのみなさま。
コード監査 by AT コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったティップスや方法に関して教えていただけるとありがたいです。出来立ての若いコードの場合は、まずどこを探りますか?。古いコードの場合は?。
テオ: 一番のティップスは、今よりももっと良いプログラマーになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べること、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だよ。これを読む人の中の果たして何人が、libcの全ての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。(どういうことかって言うと、今までソースツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていて、一文字余計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと)
APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマーが、間違ったマニュアルに重ねて間違ったプログラムを書いていた…。
---------- フォロー下さったnumaさんと、日記でチェックしてくれたdsegさんのおかげで、少し修正しました。どうもありがとうございます。
第一段落末尾のsloppyが「いい具合じゃない」と書きましたが、もっと強い否定の意味にした方が良いかもしれません。
# extraが副詞なのは、場所で分かるべきべきべき。 # セマンティクスはこなれた訳語がありますか?。最終的にこれ読む人はほとんど分かるからオッケー?。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
飛び入りで参加します (スコア:1)
Code-auditing by AT
コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったティップスや方法に関して教えていただけるとありがたいです。仕上がったばかりのコードの場合は、まずどこを探りますか?。成熟したコードの場合は?。
Theo:
一番のティップスは、今よりももっと良いプログラマーになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べること、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だよ。これを読む人の中の果たして何人が、libcの全ての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。(どういうことかって言うと、今までソースツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていたし、もし一文字足してしてヌル文字で終端するだけのつもりなら、それはやっぱりいい具合じゃないってこと)
APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらある。それを僕らが見つけた時には、すでに多くのプログラマーがその間違ったやり方でプログラムを書いていた…。
----------
ssh使わない日はないし、BSDが押され気味なのはちょっと悔しいし、どれくらい直されるのかを見てみたいと言う恐いもの見たさでやってみました。
訳に迷っているところばかりですけれど、特に一番最後
が怪しいです。私の訳だと、 になっていますから。本当は「間違ったマニュアルを元にさらに間違ってコーディングされていた」ってことかな。strncat()とstrncpy()のくだりも、manは読みましたが、
が自信ありません。万年Hello worldなものでして。Re:飛び入りで参加します (スコア:1)
strcat/strcpy はバッファオーバーフローの元凶だということで strncat/strncpy に置き換えるのだが,それの使い方がなってないと言うことでしょうね. strncat/strncpy は,第3引数に「コピーする文字列のバイト数」を渡すけれど,これには終端のヌル文字を含まないので,うっかりそれを忘れてバッファの残りサイズをそのまま渡すと,
ということになります.はっきりいってわかりにくいし,使いにくいので,その代わりに strlcat/strlcpy があるのですが.
フォローありがとうございます (スコア:1)
numaさん、こんにちは。フォロー下さいましてどうもありがとうございます。うーん、じぇんじぇん違うですね。
仕事が退けたらnumaさんにいただいたのをもとにググって、該当部分を書き直してみます。一回で済まずに、お手間をとらせることになってごめんなさい > yhさん。
私などより、よほどましに訳せて、ここらの文脈に明るい方がいらっしゃると思いますので助け舟お願いします > お読みのみなさま。
修正しました (スコア:1)
コード監査 by AT
コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったティップスや方法に関して教えていただけるとありがたいです。出来立ての若いコードの場合は、まずどこを探りますか?。古いコードの場合は?。
テオ:
一番のティップスは、今よりももっと良いプログラマーになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べること、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だよ。これを読む人の中の果たして何人が、libcの全ての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。(どういうことかって言うと、今までソースツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていて、一文字余計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと)
APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマーが、間違ったマニュアルに重ねて間違ったプログラムを書いていた…。
----------
フォロー下さったnumaさんと、日記でチェックしてくれたdsegさんのおかげで、少し修正しました。どうもありがとうございます。
第一段落末尾のsloppyが「いい具合じゃない」と書きましたが、もっと強い否定の意味にした方が良いかもしれません。
# extraが副詞なのは、場所で分かるべきべきべき。
# セマンティクスはこなれた訳語がありますか?。最終的にこれ読む人はほとんど分かるからオッケー?。