Implementation Notes

この付録には主にgawkの実装者(implementor)や保守者(maintainer)にと って重要な情報がある。すべては他の実装系ではなく、特別にgawkにあ てはまる。

互換性とデバッグ

POSIXのawkにはない、GNUによるawk言語やプログラムに対する拡 張はセクション POSIX awkにはないgawkの拡張を参照にまとめられている。これ らの機能は全て、`--traditional' オプションや `--posix'オプショ ンと共にgawkを起動することにより禁止することができる。

gawkがデバッグのために`-DDEBUG'をつけてコンパイルされた 場合、使えるコマンドラインオプションが一つ増える。

-W parsedebug

--parsedebug

プログラムを解析した結果である解析スタックの情報を出力する。

このオプションはgawk開発者(developer)にのみ適用され、一般のユーザー は使えない。実行速度を低下させてしまうので、あなたの使っているgawkではこのオ プションが使えないようにコンパイルされているだろう。

gawkに追加を行う

もしあなたがあなたが有意義な方法でgawkの質を高めることを望むなら、 あなたは全く自由にそれを行うことができる。 重要なのは、フリーソフトウェアの所有についてのポイントであり、 ソースコードは自由に入手可能であり、あなたの望むように 変更できる(セクション GNU GENERAL PUBLIC LICENSEを参照)。

このセクションでは、現在我々がgawkに対して行なおうとしている拡張の説 明を簡単に行なう。

Adding New Features

あなたがgawkに対して好きなように新しい機能を追加することは自由で ある。しかし、あなたがおこなった変更点をgawkの配布キットに含めた いと思うのなら、その変更点を私(元の開発者)が適用できるようにするための幾 つかのステップを通る必要がある。

1. 最新バージョンを入手する。これは最新のgawkの配布バージョンに対し ての変更がもっとも手間がかからないものだからである。もし、あなたの使った gawkが非常に古いバージョンだったりしたら、私は変更点のすべてを取 り込むことはできないかもしれない。gawkの最新バージョンの入手に関 する情報はセクション Getting the gawk Distributionを参照。
2. GNU Coding Standardsに従う。 このドキュメントはGNUソフトウェアがどのように書かれるべきかについて 説明している。もし、まだこれを読んだことがないのであれば、 どうぞgawkの変更を始める前に読んで欲しい。 (GNU Coding Standardsは、FSFからのAutoconfの 配布の一部として入手することができる)。
3. gawkのスタイルを使用する。 gawkのCソースコードはGNU Coding Standardsに従っているが、 幾つかの小さな例外がある。ソースコードのフォーマットは(特にブレースの 位置について)"K&R"スタイルを使用しており、タブを使っている。簡単に まとめると、gawkのコーディングルールは、
   • 関数を定義するときにはオールドスタイル(非プロトタイプ)の 関数ヘッダを使う。
   • 関数名をそれがある行の先頭に置く。
   • たとえ戻り値の型がintであっても、関数の戻り値の型を 関数名と関数の引数がある行の上の行に記述する。
   • 関数の引数を宣言するときにはインデントをつけない。
   • 制御構造(if, while, for, do, switch, return)を使う場合のカッコの回りには空白を置く。
   • 関数呼び出しに使うカッコの前にはスペースを置かない。
   • すべてのCの演算子の回りには空白を置き、関数呼び出し中の カンマの後にも空白を置く。
   • 多重の副作用を作り出すためにカンマ演算子を使わないこと。 ただし、forループの初期化部分や、incremnt part、 マクロの本体は除く。
   • インデントにはタブコードを使い、スペースを使わない。
   • "K&R"のカッコのレイアウトスタイルを使う。
   • if文、while文、for文の条件部分、 switch文のcaseでは、 ポインタやキャラクタの値だけの代わりに、 NULLや'\0'に対する比較を使う。
   • 1や0の代わりに、 TRUE、FALSE、NULLといった シンボリックな定数や、適切なところで\0というキャラクタ定数 を使用する。
   • 関数毎にその関数を説明するコメントをつける。
   • `#elif'を使わない。 UNIX上で動作する多くの古いCコンパイラはこれを扱うことができない。
   • スタックからメモリーを割り付ける関数であるallocaを使わない。 これを使用することによって、(割り付けた領域を陽にfreeしなくても良いという) ちょっとした利益を受けるよりも重大なトラブルが引き起こされる。 allocaの代わりに、mallocとfreeを使うように。
   もし私(原著者)があなたのコードを、このようなコーディングスタイルに書き直 さなければならないのならば、私はそれを面倒に思うだろう。
4. appropriate paper workにサインする準備をする。FSFにあなたの変更を配布さ せるようにするには、その変更をパブリックドメインに置き、有効なサイン付き の声明書を提出するか、変更点に関する著作権をFSFに譲渡するかのどちらかを 行わなければならない。これらのアクションは両方とも簡単なものであり、既に 多くの人達がこれを行っている。 もしなにか疑問があれば、私(セクション 問題やバグの報告を参照)、 か、gnu@gnu.orgに連絡して欲しい (セクション 問題やバグの報告を参照)。
5. ドキュメントの更新。 あなたの新しいコードに沿って、このマニュアルのための新しいセクショ ン、もしくは章を提供して欲しい。もし可能ならば、通常のフォーマットされて ないASCIIテキストではなく(それでもないよりは良いが)、Texinfoを使って欲し い。Effective AWK Programmingで使っている書式は、Texinfoソースファイルの `@bye'の後にある。可能ならば、マニュアルページも同じように更新して 欲しい。 あなたは同様にドキュメントの変更に対する手続き書類に署名しなければ ならないだろう。
6. 変更に関しての文脈差分(context diff)または 単一化差分(unified diff)を提 出する。オリジナルのgawkのソースツリーと、あなたの修正したバージ ョンのgawkとの比較を`diff -c -r -N' か`diff -u -r -N'を 使って行う(私は文脈差分のほうが読みやすいと思う。しかし、単一化差分のほ うが小さくなる)。ここで、GNUバージョンのdiffを使うことをお薦めす る。diffの実行によって生成された出力を私に送って欲しい。電子メイ ルの情報はセクション 問題やバグの報告を参照。 この書式を使う事によって、私があなたの変更をgawkのソースコードの マスターバージョンに(patchを使って)適用するのが簡単になる。もし変 更を手作業でやる必要があるならテキストエディタを使って行うが、特に変更点 が多数あった場合には私はそれをできないかもしれない。

多くの作業があるように思えるかもしれないが、あなたは新しいコードを書くこ とができたとして、私はそれをメンテナンスし、サポートしなければならない ということを忘れないで欲しい。

Porting gawk to a New Operating System

gawkを新しいオペレーティングシステムに移植したい場合、 以下に挙げるような幾つかのステップがある。

1. コーディングスタイル、diffの提出などに関して セクション Adding New Featuresを参照,にある ガイドラインに従う。
2. 移植を行うときには、あなたの書くコードは、gawkの残りの部分や、他 の移植と共存しなければならないということに注意すること。システムに関係な い部分のコードを変更しないようにし、もし可能ならば、移植のためのコードを 単に`#ifdef'をばらまくような形で行わないこと。 もし特定なシステムのために必要とされた変更が、コード全体のあまりに多くに 影響するならば、私は恐らくその変更を受け入れないだろう。このような場合で も、もちろん、あなたはあなたの行った変更を GPL(セクション GNU GENERAL PUBLIC LICENSEを参照). に従って配布することができる。
3. gawkを構成するファイルの幾つかはFree Software Foundationの他の人 々によってメンテナンスされている。したがって、はっきりした理由がない限り は、そのようなコードの変更は行うべきではない。つまり、変更は不可能ではな いが、これらにファイルに対する変更は慎重に、注意深く調べられることになる。 該当するファイルとしては、`alloca.c', `getopt.h', `getopt.c', `getopt1.c', `regex.h', `regex.c', `dfa.h', `dfa.c', `install-sh', `mkinstalldirs'がある。
4. 移植をメンテナンスし続けることを厭わないこと。UNIX以外のオペレーティング システムは、そのようなシステムでgawkをコンパイルしたり実行したり するのに必要なコードをメンテナンスしているボランティアによってサポートさ れている。もし、その様なメンテナンスを行うボランティアが誰もいなければ、 その移植はサポート外のものとなり、配布キットから取り除く必要が生じるかも しれない。
5. 適切な`gawkmisc.???'ファイルを提供する。各移植はオペレーティングシ ステム固有の機能を実装するそれぞれの`gawkmisc.???'を持っている。こ れはコード本体に`#ifdef'を使って埋めこむよりも明快である。メインソ ースディレクトリにある`gawkmisc.c'は適切な`gawkmisc.???'ファイ ルを各サブディレクトリからインクルードする。それらも同様に更新することを 忘れないように。 各移植毎の`gawkmisc.???'ファイルは、 移植先のマシンやオペレーティングシステムを連想させるような拡張子がついている。 たとえば、`pc/gawkmisc.pc' や`vms/gawkmisc.vms'といったものがある。 単なる`gawkmisc.c'ではなく別々の拡張子を使うことによって、 ファイルを移植ごとのサブディレクトリからメインのサブディレクトリに 本当の`gawkmisc.c'ファイルを壊すことなく持ってくることが 可能になる(現在のところ、これはMS-DOSとOS-2への移植のみの事柄である)。
6. あなたの使っているオペレーティングシステムで必要となる`Makefile'、C のソースファイルおよびヘッダファイルを提供する。あなたの書いたコードは別 のサブディレクトリに入るようにすべきで、ファイル名は使用するオペレーティ ングシステムやマシンと同じか、簡単に連想できるような名前を持っているよう にする。
7. ドキュメントを更新する。 あなたの移植したシステム上でgawkをインストール、コンパイル するのに必要なステップを記述したこのマニュアルのセクション を書いて欲しい。
8. 適切な事務手続きに署名する準備をする。FSFがあなたのコードを配布するため に、あなたはあなたのコードをパブリックドメインに置いてそのための署名され た宣言書を提出するか、あなたのコードの著作権をFSFに委譲するかしなければ ならない。

これらのステップに従うことによって、あなたのgawkに対する変更をま とめることが容易になり。すでにある他のオペレーティングシステムへ移植する ためのコードと問題なく共存できるようになるのである。

あなたが提供し、メンテナンスするコードの中では、コーディングスタイルやブ レースの配置をあなたの好きなようにすることができる。

将来予定されている拡張

AWKはPERLに似た言語であるが、ちょっとばかし洗練されている。
Arnold Robbins

おい!
Larry Wall

このセクションでは、現在我々がgawkに対して 行おうとしている拡張や、可能な改良点について簡単に説明する。 gawkの配布キットにある`FUTURES' というファイルにはこれらの拡張がリストアップされている。

以下のリストはawkプログラマーにとって有用な、 将来行われるだろう改良案である。

ローカライズ

GNUプロジェクトは複数言語(multiple languages)のサポートを開始した。 少なくとも、gawkが警告やエラーのメッセージを英語以外の 言語で出力することを可能とする。 これはおそらく、awkプログラムも同様に複数言語機能 を使えるようになり、gawkそのものとは分離される。

データベース

awkの配列をGDBM/NDBM/SDBMのファイルにマッピングすることを 可能にする。

配列 PROCINFO

プロセスに関係した情報を提供する特殊ファイル (セクション Special File Names in gawkを参照) は、同じ情報をより簡単なやり方で提供する 配列PROCINFOに取って代わられる。

lint によるより多くの警告

移植性のためのチェック事項をより多くする。

サブプロセスの環境の制御

gawkのプログラム中で配列ENVIRONの内容を 変更すると、gawkから実行する子プロセスにそれが伝播する。

以下のリストはgawkの能力をより向上させることのできる 改良である。

改良されたdfa

GNU grepから持ってきたdfaパターンマッチャーは幾つかの問題を 抱えている。新しく作るにしろ、問題点を修正するにしろ、一部の重要な正規表現 のマッチングがこれを扱っている。

mmapの使用

mmapシステムコールをサポートしているシステムでは、それを 使うことによってファイルからの入力を高速化し、入力バッファの 管理をかなり簡単にできるだろう。

GNU mallocの使用

gawkは動的なメモリ割当を多用してるので、GNUによる mallocを使うことによってgawkを高速化できる可能性がある。

改良の提案

以下に挙げるのは gawkハッカーが望むであろう幾つかの プロジェクトである。作業に要するのは数日から数週間であるが、 プロジェクトやプログラマーの能力にもよる。 もしなんらかの改良を行ったのなら、GNUプロジェクトの担当者まで 送って欲しい。 gawkに新しく機能を追加するときに従うガイドラインは セクション Adding New Featuresを参照, にある。 メンテナンス担当者へコンタクトするための情報は セクション 問題やバグの報告を参照.

1. awkプログラムのコンパイル。gawkは与えられた文法を解析木に変換 するのにBison(YACCライクな)パーサを使っている。解析木は単純な再帰的評価器に よって実行される。このやり方は、再帰的評価器が単純なことであっても多くの手続 きを呼出す為に大きなオーバーヘッドを招く。 gawkがスクリプトを解析し、ユーザーがコンパイルできるような Cプログラ ムに変換するのを可能にする為に、普通のCコンパイラと、必要とされる関数全て (正規表現、フィールド、連想配列、type coercion など)を提供する 特別なgawkライブラリが使われる。 もっと実現しやすいのはawkの中間フェイズで解析木を、GNU Emacs Lispで 使用されているようなリニアバイトコードに変換するということである。再帰的評 価器はstraight line byte code インタプリタに置き換えられるだろう。このイン タプリタはコンパイルしたプログラムの実行速度とgawkの現在の動作 速度の中間で動作する。
2. The programs in the test suite could use documenting in this マニュアル. テスト用のプログラムをこのマニュアルに記述する。
3. そのほかのアイデアについては`FUTURES'というファイルを参照のこと。 もしここに挙げた以外に良いアイデアがあれば我々に教えて欲しい。