メイン | 2006年10月 »

double-linked list

double-linked list は「双方向リンクリスト」と訳していますが、「二重リンクリスト」になっている部分もあったので、全部双方向に統一しました。

forward/backward pointer

リンク: sccc: 第4章に関する話題.

forward link を前方リンクと訳すと、「前のブロック」の「前」と混乱します。 「順方向リンク」と訳すのはいかがでしょうか?

backward link は「逆方向リンク」。

単純に置き換えちゃおうかとも思ったが、forward and backward pointers は「前方後方ポインタ」と訳している。さすがにこれを「順方向逆方向ポインタ」とするわけにはいくまい。「双方向」だと誤解されそうだ。「順逆方向」もなあ。「順方向および逆方向のポインタ」が一番無難だが、文章のリズムがくずれてしまう。困った。困った。

in other words

リンク: sccc: 第4章に関する話題.

In other words, the unlink() macro writes four bytes of data supplied by an attacker to a four-byte address also supplied by the attacker.

の部分が、図 4-14 の用語と異なるので分かりにくいです。

この文は、僕はあまり違和感がないのだけど。それまで説明してきたことによって生じる結果を自然言語で言い直しているように読めます。

make sure

リンク: sccc: 第4章に関する話題.

unlink の所ですが、 The malicious argument, of course, makes sure that the location where dlmalloc finds the PREV_INUSE bit is clear, tricking dlmalloc into believing the second chunk is unallocated--so the free() operation invokes the unlink() macro to consolidate the two chunks. の訳が、内容がわかってないのに訳しているような訳になっています。

-4 と書くことで、3番目のブロックではなく、2番目、すなわち自分自身を読み込ませるところがポイントです。
-4 ずれているので、先頭4バイトがサイズになります。
これを「偶数」にしておけば、IN_USE ビットが落ちていることになり、2番目のブロックがフリーだと騙せるわけです。

図4-14 に「even」と書いてあるのは、そういう意味です。ここも「偶数」と訳す方が親切でしょう。

なので、「確認する」という訳は誤りです。

「dlmalloc が IN_USE ビットが落ちていると思い込ませ」ぐらいでしょうね。

make sure には『手段を講じる』という意味もあるようだけど、そんな使い方ですかね。

「もちろん」がちょっと浮いちゃってるな。

アンリンク

リンク: sccc: 第4章に関する話題.

4-11 に「アンリンク」ですが、 unlink() マクロの動作例ですね? unlink() が断りなく、カタカナに直されているので、 一瞬理解できませんでした。

これは悩ましい。前の方の文章に無理矢理「アンリンク」を入れました。

無効なポインタでアクセスはできるか

リンク: sccc: 第4章に関する話題.

4.2.7 の except that the returned pointer cannot be used to access an object.

を「アクセスすることはできない」と訳していますが、
アクセスすると変になるだけで、アクセスはできるでしょう。used も訳されていないので、違和感があります。

アクセスに利用してはならないことを除いては、値が 0 でないときと同じように

ぐらいではないでしょうか?

そかなー。僕は「木の葉を使って買い物をすることはできない」は「木の葉で買い物はできない」と訳しちゃいます。確かに木の葉で支払おうとすることはできるわけですが、だからといって買い物はできるが商品をもらえないだけだとというのは、ちょっと。

タイトルの不整合

リンク: sccc: 第4章に関する話題.

最初の「量が」の訳は違和感があります。 「大きさが」の方がよくありませんか?

4.2 の最初で、4.2.1 などの見出しを列挙していますが、
訳が一致していません。見出しの訳を単純に列挙すべきです。

同じ表現を使っている部分は統一しました。

consolidate

リンク: sccc: 第4章に関する話題.

Memory chunks are consolidated during the free() operation. If the chunk located immediately before the chunk to be freed is free, it is taken off its double-linked list and consolidated with the chunk being freed. Then, if the chunk located immediately after the chunk to be freed is free, it is taken off its double-linked list and consolidated with the chunk being freed. The resulting consolidated chunk is placed in the appropriate bin.

ここの訳し方は、変ではないですか?
第三文は、第一文と第二文の両方を受けているはずです。

あと、「統合」というのは大げさではないですか?
連結、あるいは結合ぐらいでいいと思います。

Memory chunks are consolidated during the free() operation. If the chunk located immediately before the chunk to be freed is free, it is taken off its double-linked list and consolidated with the chunk being freed.

メモリブロックは、free() によって連結されることがある。
もし、解放しようとしているメモリブロックの直前の
メモリブロックがフリーなら、二重リンクから外され、
解放しようとしているメモリブロックと連結される。

Then, if the chunk located immediately after the chunk to be freed is free, it is taken off its double-linked list and consolidated with the chunk being freed.

もし、解放しようとしているメモリブロックの直後の
メモリブロックがフリーなら、二重リンクから外され、
解放しようとしているメモリブロックと連結される。

The resulting consolidated chunk is placed in the appropriate bin.

そして、このように連結されたメモリブロックは、
適切な bin に挿入される。

なるほど、単にフリーブロックを取り出して、新しいのとくっつけると解釈すれば、どっちをどっちにと考える必要はないわけだ。

連結はリンクと区別しにくいので結合かな。もともと英語の consolidate ってのが大袈裟な感じなので、統合の方が原文の雰囲気に近いという気もするけど。

conversely

リンク: sccc: 第4章に関する話題.

Programmers may also become confused because of the asymmetry of having to free() calls to malloc() but not to alloca(). Conversely, calling free() on a pointer not obtained by calling calloc() or malloc() is a serious error.

ここの、conversely が訳せない問題ですが、
前者の訳が意訳すぎるからでしょう。
以下でどうでしょうか?

malloc() には free() があり、alloca() にはないという非対称にプログラマは混乱するかもしれない。
逆に言えば、calloc() または malloc() を呼んで得られたんではないポインターを free() に渡すのは、
深刻な間違いである。

前者は、free() を従、後者は free() を主として表現しているので、逆に言えば、となるのでしょう。

やっぱり、日本語で「逆に言えば」というのとちょっと違うんじゃないかと思うのです。「別の言い方をすれば」ってのとも違うし、結局訳さないのが一番いいのではないかと。

Running with Scissors

Chapter 1 のタイトルは Running with Scissors なのだが、この日本語訳が問題。
今は苦し紛れに「今そこにある危機」と訳してある。
著者に相談したら、Running with Scissors は危ないことを表す表現なので、そんな感じならなんでもいいんじゃないかという意見らしいが、まさか「キチガイに刃物」とするわけにもいくまい。

http://www.amazon.co.jp/exec/obidos/ASIN/4901784560 は「ハサミを持って突っ走る」。こういう手もあるか?

ヘンリー L. メンケン

この本各章の冒頭には何か邪悪なものに関連する引用がおかれていて、これが悩みの種なのである。 一応7章までについては出典を探すことができたのだが、8章だけが残っている。こういうもの。
Evil is that which one believes of others.
It is a sin to believe evil of others, but it is seldom a mistake.
--Henry Lewis Mencken
A Mencken Chrestomathy, Chapter 30, p. 617, Knopf (1949)
後半部分については、ウェブを検索するとこう訳されているものがいくつも見つかる。
人間は邪悪なものであると考えるのは罪である。だが、たいていの場合、間違ってはいない。
でも前半がわからないのです。 出典または定訳があれば是非教えてください。

arc injection の日本語訳

2章に arc injection という攻撃手法が出てくる。説明はこう。

arc インジェクションは、コードを注入する代わりに、決められたプログラムの制御フローグラフの中に、新しい arc (つまり制御フローの切り替え) を挿入するのである。

今は、このように「arc インジェクション」と書いてあるが、グラフ理論ではノードとノードをつなぐものをアークと呼ぶらしい。日本語では弧ということもある。とりあえず、その分野では「アーク」という言葉は一般的に使われているようなので、最終版でも「アークインジェクション」としようかと思っている。

第8章に関する話題

この記事にコメントください。

第7章に関する話題

この記事にコメントください。

第6章に関する話題

この記事にコメントください。

第5章に関する話題

この記事にコメントください。

第4章に関する話題

この記事にコメントください。

第3章に関する話題

この記事にコメントください。

第2章に関する話題

この記事にコメントください。

第1章に関する話題

この記事にコメントください。

全体と前書きに関する話題

この記事にコメントください。

Secure Coding in C and C++ に関する情報交換のためのページです

「Secure Coding in C And C++」の日本語訳を11月に出版する予定です。現在翻訳の内容を最終調整しているところで、その情報共有に使うことができればいいと思っています。新しい話題を書きたい場合は、それぞれのカテゴリーの先頭の記事にコメントしてください。

原書情報
Secure Coding in C And C++
SEI Series in Software Engineering
Robert C. Seacord
http://www.amazon.co.jp/exec/obidos/ASIN/0321335724