« 第3章に関する話題 | メイン | 第5章に関する話題 »

第4章に関する話題

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

トラックバック

このページのトラックバックURL:
http://www.typepad.jp/t/trackback/6543631

このページへのトラックバック一覧 第4章に関する話題:

コメント

山本です。

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

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

やっぱり、そうだよなあ。

「順方向」「逆方向」は悪くないのですが、「前方および後方ポインタ」というような表現になると、若干くどい印象があります。まあ、割り切ればいいだけだけど。

「前進」「後退」はどうかなあとも思ってました。

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() を主として表現しているので、逆に言えば、となるのでしょう。

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 に挿入される。

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

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

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

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

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

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

4.3.1 では「末尾4バイト」となっていますが、
図4-8 では「最後の4バイト」となっています。
分かりにくいので統一した方がいいでしょう。

あと、4-8 の「サイズまたは前ブロックの最後の4バイト」は、誤解を与えます。
「前ブロックのサイズ、または前ブロックの最後の4バイト」でしょうね。

図 4-9 が、つまりは bin なのですよね?
図に bin が出てこないので、理解しにくいです。

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

アンリンク技法

argv のことを引数と訳していますが、関数の引数と混同しやすいです。「コマンドライン引数」のように十分に情報を与える方がいいでしょう。

とくに「悪意のあるコマンドライン引数」の方は、コマンドラインが付かないと、とっても分かりにくいです。

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 ビットが落ちていると思い込ませ」ぐらいでしょうね。

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 の用語と異なるので分かりにくいです。

データは、図では addr
アドレスは、図では fp

ですね。

データ(addr)をアドレス(fp)に書き込んでしまう。ぐらい、くどく訳さないと分からないでしょう。

あと FP + 12 = fp とはっきり書かれてないので、分かりにくいです。
fp は関数へのポインタと言う意味でしょうが、
説明がないので理解しにくいです。

図 4-15 では、fp が出てきて
4-16 では fd だったり、
fp は FUNCTION_POINTER だったりと、
統一感がまったくありません。

コメントを投稿