長南洋一
cyoic****@maple*****
2014年 9月 16日 (火) 21:51:25 JST
Fork長南です。
えい、どうせだ、と未訳の tsort と ptx を訳してみました。
どちらも、よく知らないことなので、あやしげな訳になっているかも
しれません。
coreutils.info は長すぎるので、tsort と ptx の部分だけ、整形したものを
プレーンテキストにしました。まず、tsort を送ります。
添付した tsort.tar.gz には、原文と訳文のプレーンテキスト版が入って
います (tsort-info.txt と tsort-ja-info.txt)。
さて、tsort のよくわからないところです。
○「7.6 `tsort': トポロジカル・ソート」
Consider a more realistic example. You have a large set of functions
all in one file, and they may all be declared static except one.
Currently that one (say 'main') is the first function defined in the
file, and the ones it calls directly follow it, followed by those they
call, etc. Let's say that you are determined to take advantage of
prototypes, so you have to choose between declaring all of those
functions (which means duplicating a lot of information from the
definitions) and rearranging the functions so that as many as possible
are defined before they are used. One way to automate the latter
process is to get a list for each function of the functions it calls
directly. Many programs can generate such lists. They describe a call
graph. Consider the following list, in which a given line indicates
that the function on the left calls the one on the right directly.
もっと現実的な例を考えてみよう。たくさんの関数をすべて一つのファイル
に書いているとしよう。しかも、一つを除いて、他のすべての関数を static
として宣言している。現在のところ、その例外 (`main' ということにする)
が、ファイル中で定義されている最初の関数であり、それが直接呼び出す
関数群がそれに続き、さらにその後に、その関数群が呼び出す関数が続く ...
という形になっている。さて、ここで、プロトタイプを利用することにしたと
しよう。そうなると、呼び出される関数のすべてを宣言するか (そのためには、
定義の部分から情報をどっさりコピーしなければならない）、あるいは、
できるだけ多くの関数が、使用される前に定義されているように、関数群を
並べ替えるか、どちらかを選ばなければならない。後者の作業を自動化する
方法の一つが、各関数についてそれが直接呼び出す関数のリストを作成する
ことである。そうしたリストを生成するプログラムはたくさんある。いわゆる
コール・グラフを作成するプログラムだ。以下のリストをご覧になって
いただきたい。各行は、左側の関数が右側の関数を直接呼び出していることを
示している。
プログラミングについては、イロハしか知らず、それもうろ覚えなので、
たどたどしい訳になっています。上の訳に、内容や用語のおかしいところは
ありませんか。特に、「static」とか「プロトタイプ」とかの言葉の使い方は
正しいでしょうか。お気づきのことがあったら、教えていただけると、
ありがたいと思います。
○「7.6.1 `tsort': 誕生の背景」
この節は、ほとんど全部自信がありません。でも、強いて言えば、この部分。
'tsort' exists because very early versions of the Unix linker processed
an archive file exactly once, and in order. As 'ld' read each object in
the archive, it decided whether it was needed in the program based on
whether it defined any symbols which were undefined at that point in the
link.
This meant that dependencies within the archive had to be handled
specially. For example, 'scanf' probably calls 'read'. That means that
in a single pass through an archive, it was important for 'scanf.o' to
appear before read.o, because otherwise a program which calls 'scanf'
but not 'read' might end up with an unexpected unresolved reference to
'read'.
`tsort' が存在しているのは、Unix のリンカのごく初期のバージョンでは、
一つのアーカイブファイルの処理をたった一回しか行わず、それも、
ファイルの最初から最後へと順番に見ていくだけだったからである。`ld'
は、アーカイブ中の各オブジェクトを読み込むとき、そのオブジェクトが
プログラムに必要かどうかの判断を、リンク作業のその時点でまだ定義
されていない何らかのシンボルを定義しているかどうかを基準にして
行っていた。
そのため、アーカイブ中の依存関係には、特別な扱いが必要になった。
たとえば、`scanf' はたぶん `read' を呼んでいる。それは、リンカが
アーカイブをたった一回最初から順番に読んで行くとき、`scanf.o' が
`read.o' より前にあることが重要だったということである。なぜなら、
そうなっていないと、`scanf' を呼ぶけれど、`read' を呼ばないプログラム
では、`read' に対する参照が、予期に反して "unresolved" になってしまい
かねなかったからだ。
"unexpected unresolved reference to ..." というエラーメッセージが出る
のではなく、"unresolved reference to ..." というエラーメッセージが出て、
それが unexpected だということですね。"unresolved" は日本語にした方が
よいかどうか。その場合、「未解決」か「解決不能」か。debian wheezy の
gcc では英語のままのようですが。
なぜなら、そうなっていないと、`scanf' を呼ぶけれど、`read' を呼ばない
プログラムでは、"unresolved reference to 'read'" という予期に反する
結果になってしまいかねなかったからである。
と、エラーメッセージの部分をそのまま引用する手もありそうです。
"unexpected" については、「予想 (期待)を裏切る」とか「意外な」とか
「思惑外れの」とか、いろいろ考えているのですが、ピッタリした訳を
まだ思いついていません。
--
長南洋一
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: tsort.tar.gz
型: application/octet-stream
サイズ: 4742 バイト
説明: 無し
Download