| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Unix と VMS のファイルシステムの差異により、GCC は ‘#include’ で 指定されたファイル名を VMS が理解できる名前に変換する。 基本的な戦略は、インクルードファイルであることを指定するプレフィックスを 前に付け、ファイル名全体を VMS のファイル名に変換し、その後で ファイルのオープンを試みる。GCC はどれか成功するまで、 色々なプレフィックスを一つずつ試す。
この変換の仕組みは次の通りである。最初のディレクトリ名がデバイスになり、 残りのディレクトリが VMS 形式のディレクトリ名に変換される。 例えば、‘X11/foobar.h’ という名前は ‘X11:[000000]foobar.h’ か ‘X11:foobar.h’ に変換され、このように変換されしまえばオープン可能になる。 この戦略により、論理名をヘッダファイルの実際の位置を指すように割り当てる ことができるようになる。
次の形の include 制御子は、
#include foobar |
良くある VAX-C と GCC の非互換性の元である。VAX-C はこれを標準の
#include <foobar.h> 制御子のように取り扱う。
これは、GCC が実装している ANSI C の動作と互換性がない。
ANSI C dへあ、名前 foobar をマクロとして展開する。
マクロ展開の結果は最終手k位に #include の二つの標準形の
一つを生じる必要がある。
#include "file" #include <file> |
この問題に出会ったら、一番良い解決方法はソースコードを修正して、
#include 制御子を二つの標準形のうちの一つに変換することである。
そうすれば、どちらのコンパイラでも動作する。急ぎで汚い修正でよければ、
ファイル名を、以下のように、適切に展開されるマクロとして定義する方法もある。
#define stdio <stdio.h> |
これは、その名前がプログラム中の他のものとぶつからない限りにおいて、 正しく動作するだろう。
もう一つの非互換性の元は、VAX-C は、
#include "foobar" |
と書いた場合、実際には ‘foobar.h’ を要求していると 仮定していることである。GCC はこんな仮定はしておらず、指定されたもの そのままを受け取り、‘foobar’ というファイルを読み込もうとする。 この問題を回避する最善の方法は、include 命令で適切なファイル拡張子を 常に指定することである。
VMS 用 GCC は、ほとんどの汎用のプログラムをコンパイルするのに
充分なインクルードファイルのセットとともに配布されている。
GCC の配布には、いくつかのVMS システム固有の関数用の定数や構造体を
定義するヘッダファイルが含まれていないが、かといって、これらの関数に
ついて GCC が使えないということはない。まず、パブリックドメインの
ユーティリティ UNSDL(DECUS のテープに入っている)を使うか、
あるいは、システムのマクロライブラリの一つから適切なモジュールを
抜き出す課して、ヘッダファイルを生成あるいは作って置き、
次にエディタを使って C のヘッダファイルを構築しなければならないだろう。
#include に指定するファイル名には、DECNET のノード名を
含めることはできない。ノード名を明示的に、あるいは論理名を
通じて間接的に使おうとすると、プリプロセッサは入出力エラーを出す。
This document was generated
using texi2html 1.78.