OpenVMS
HP C ランタイム・ライブラリ・
リファレンス・マニュアル (上巻)

1.5 ヘッダ・ファイル制御のための機能テスト・マクロ

機能テスト・マクロは，移植可能なプログラムを作成するための手段を提供します。これらのマクロを使用すると，プログラムで使用する HP C RTL シンボル名がインプリメンテーションで提供されるシンボル名と競合しないかどうか確認できます。

HP C RTL のヘッダ・ファイルは，多くの機能テスト・マクロの使用をサポートするようにコーディングされています。アプリケーションで機能テスト・マクロを定義した場合， HP C RTL ヘッダ・ファイルはその機能テスト・マクロで定義されているシンボルとプロトタイプだけを提供し，それ以外のものは提供しません。プログラムでこのようなマクロを定義しないと， HP C RTL ヘッダ・ファイルは無制限にシンボルを定義します。

HP C RTL でサポートされる機能テスト・マクロは，次に示すようにヘッダ・ファイル内のシンボルの有効性を制御するために，大きく 3 種類に分類されます。

標準
複数バージョンのサポート
互換性

1.5.1 標準マクロ

HP C RTL では，次の標準の一部がインプリメントされています。

XPG4 V2 (X/Open CAE Specification, System Interfaces and Headers, Issue 4, Version 2)
XPG4 (X/Open CAE Specification, System Interfaces and Headers, Issue 4)
POSIX 1003.1c-1995 または IEEE 1003.1c-1995 (Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)--- Amendment 2:Threads Extension [C Language])
ISO POSIX-2 (ISO/IEC 9945-2:1993 - Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities)
ISO POSIX-1 (ISO/IEC 9945-1:1990 - Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Programming Interface (API) (C Language))
ANSI/ISO/IEC 9899:1999---ISO が 1999 年 12 月に公開し， ANSI 標準で 2000 年 4 月に採用された C99 標準
ISO C，Amendment 1 (ISO/IEC 9899:1990-1994 - Programming Languages - C，Amendment 1: Integrity)
ISO C (ISO/IEC 9899:1990 - Programming Languages - C)--- 標準部分は ANSI C (X3.159-1989, American National Standard for Information Systems - Programming Language C) と同じ

1.5.2 標準の選択

機能テスト・マクロを定義することにより，各標準を選択することができます。このようにマクロを定義するには，ヘッダ・ファイルを取り込む前に， C ソースで #defineプリプロセッサ・ディレクティブを使用するか， CC コマンド・ラインに /DEFINE 修飾子を指定します。

表 1-4 は，標準のサポートを制御する HP C RTL 機能テスト・マクロを示しています。

表 1-4 機能テスト・マクロ---標準
マクロ名選択される標準暗黙に選択される他の標準説明

_XOPEN_SOURCE_EXTENDED XPG4 V2 XPG4，ISO POSIX-2，ISO POSIX-1，ANSI C 以前は X/Open で採用されていなかった従来の UNIX ベースのインタフェースも含めて， XPG4 拡張機能が有効になる。

_XOPEN_SOURCE XPG4 ISO POSIX-2，ISO POSIX-1，ANSI C XPG4 標準シンボルが有効になり， _POSIX_C_SOURCE が 2 より大きい値に定義されていない場合は， 2 に設定される ¹ ²。

_POSIX_C_SOURCE ==199506 IEEE 1003.1c-1995 ISO POSIX-2，ISO POSIX-1，ANSI C ANSI C によって定義されるヘッダ・ファイルで， IEEE 1003.1c-1995 によって要求されるシンボルが有効になる。

_POSIX_C_SOURCE ==2 ISO POSIX-2 ISO POSIX-1，ANSI C ANSI C によって定義されるヘッダ・ファイルで， ISO POSIX-2 によって要求されるシンボルの他に， ISO POSIX-1 によって要求されるシンボルも有効になる。

_POSIX_C_SOURCE ==1 ISO POSIX-1 ANSI C ANSI C によって定義されるヘッダ・ファイルで， ISO POSIX-1 によって要求されるシンボルが有効になる。

__STDC_VERSION__ ==199409 ISO C amdt 1 ANSI C ISO C Amendment 1 シンボルが有効になる。

_ANSI_C_SOURCE ANSI C --- ANSI C 標準のシンボルが有効になる。

**表 1-4 機能テスト・マクロ---標準**
マクロ名	選択される標準	暗黙に選択される他の標準	説明
`_XOPEN_SOURCE_EXTENDED`	XPG4 V2	XPG4，ISO POSIX-2，ISO POSIX-1，ANSI C	以前は X/Open で採用されていなかった従来の UNIX ベースのインタフェースも含めて， XPG4 拡張機能が有効になる。
`_XOPEN_SOURCE`	XPG4	ISO POSIX-2，ISO POSIX-1，ANSI C	XPG4 標準シンボルが有効になり， `_POSIX_C_SOURCE` が 2 より大きい値に定義されていない場合は， 2 に設定される ¹ ²。
`_POSIX_C_SOURCE` ==199506	IEEE 1003.1c-1995	ISO POSIX-2，ISO POSIX-1，ANSI C	ANSI C によって定義されるヘッダ・ファイルで， IEEE 1003.1c-1995 によって要求されるシンボルが有効になる。
`_POSIX_C_SOURCE` ==2	ISO POSIX-2	ISO POSIX-1，ANSI C	ANSI C によって定義されるヘッダ・ファイルで， ISO POSIX-2 によって要求されるシンボルの他に， ISO POSIX-1 によって要求されるシンボルも有効になる。
`_POSIX_C_SOURCE` ==1	ISO POSIX-1	ANSI C	ANSI C によって定義されるヘッダ・ファイルで， ISO POSIX-1 によって要求されるシンボルが有効になる。
`__STDC_VERSION__` ==199409	ISO C amdt 1	ANSI C	ISO C Amendment 1 シンボルが有効になる。
`_ANSI_C_SOURCE`	ANSI C	---	ANSI C 標準のシンボルが有効になる。

¹ISO C Amendment 1 には， XPG4 に指定されていないシンボルが含まれており， __STDC_VERSION__ == 199409 および _XOPEN_SOURCE (または _XOPEN_SOURCE_EXTENDED) を定義すると， ISO C と XPG4 API の両方が選択される。 XPG4 と ISO C Amendment 1 の両方を指定してコンパイルしたときに競合が発生した場合， ISO C Amendment 1 が優先される。
²XPG4 は ISO C Amendment 1 を拡張したものである。 _XOPEN_SOURCE または _XOPEN_SOURCE_EXTENDED を定義すると， ISO C API の他に，ヘッダ・ファイルで提供される XPG4 拡張機能も選択される。このコンパイル・モードでは，XPG4 拡張機能が有効になる。

ここに示した標準のいずれでも定義されていない機能は HP C 拡張機能であると解釈され，標準関連の機能テスト・マクロを定義しないことによって選択されます。

ヘッダ・ファイル定義を制御するために機能テスト・マクロを明示的に定義しなかった場合は， HP C 拡張機能も含めて，定義されているすべてのシンボルが暗黙に取り込まれます。

1.5.3 /STANDARD 修飾子との相互関係

/STANDARD 修飾子はサポートされる C 言語の方言を選択します。

/STANDARD=ANSI89 および /STANDARD=ISOC94 を除き， C 言語の方言の選択と使用する HP C RTL API の選択はそれぞれ独立して行われます。 /STANDARD に対して他の値を選択すると，拡張機能も含めて API 全体が使用可能になります。

/STANDARD=ANSI89 を指定すると，デフォルト API セットは ANSI C セットに制限されます。この場合，より広範囲にわたる API セットを選択するには，適切な機能テスト・マクロも指定する必要があります。拡張機能も含めて， ANSI C の方言とすべての API を選択するには，ヘッダ・ファイルを取り込む前に， __HIDE_FORBIDDEN_NAMESの定義を取り消します。

/STANDARD=ISOC94 を使用してコンパイルすると， __STDC_VERSION__は 199409 に設定されます。 XPG4 と ISO C Amendment 1 の両方を指定してコンパイルしたときに競合が発生した場合は， ISO C Amendment 1 が優先されます。 ISO C Amendment 1 に対する XPG4 拡張機能を選択するには， _XOPEN_SOURCEを定義します。

次の例はこれらの規則を理解するのに役立ちます。

fdopen関数は， <stdio.h>に対する ISO POSIX-1 の拡張機能です。したがって， <stdio.h>は，次の 1 つ以上の条件が満たされる場合だけ， fdopenを定義します。
- この関数を含むプログラムが厳密な ANSI C モード (/STANDARD=ANSI89) でコンパイルされていない。
- _POSIX_C_SOURCEが 1 以上の値として定義されている。
- _XOPEN_SOURCEが定義されている。
- _XOPEN_SOURCE_EXTENDEDが定義されている。
popen関数は， <stdio.h>に対する ISO POSIX-2 の拡張機能です。したがって，次の 1 つ以上の条件が満たされる場合だけ， <stdio.h>は popenを定義します。
- この関数を含むプログラムが厳密な ANSI C モード (/STANDARD=ANSI89) でコンパイルされていない。
- _POSIX_C_SOURCEが 2 以上の値として定義されている。
- _XOPEN_SOURCEが定義されている。
- _XOPEN_SOURCE_EXTENDEDが定義されている。
getw関数は， <stdio.h>に対する X/Open の拡張機能です。したがって，次の条件が 1 つ以上満たされる場合だけ， <stdio.h>は getwを定義します。
- プログラムが厳密な ANSI C モード (/STANDARD=ANSI89) でコンパイルされていない。
- _XOPEN_SOURCEが定義されている。
- _XOPEN_SOURCE_EXTENDEDが定義されている。
sysconf関数をサポートするために， X/Open の拡張シンボル定数 _SC_PAGESIZE，_SC_PAGE_SIZE，_SC_ATEXIT_MAX， _SC_IOV_MAX が <unistd.h>に追加されました。しかし，これらの定数は _POSIX_C_SOURCEでは定義されていません。
プログラムで _POSIX_C_SOURCEを定義しておらず， _XOPEN_SOURCE_EXTENDEDを定義している場合にだけ， <unistd.h>ヘッダ・ファイルはこれらの定数を定義します。
_POSIX_C_SOURCEが定義されている場合は，これらの定数は <unistd.h>で有効になりません。 _POSIX_C_SOURCEは，厳密な ANSI C モードでコンパイルされたプログラムに対してだけ定義されます。
fgetname関数は， <stdio.h>に対する HP C RTL の拡張機能です。したがって，プログラムが厳密な ANSI C モード (/STANDARD=ANSI89) でコンパイルされていない場合にだけ， <stdio.h>は fgetnameを定義します。
マクロ _PTHREAD_KEYS_MAX は POSIX 1003.1c-1995 で定義されています。このマクロは， _POSIX_C_SOURCE== 199506 と定義した状態で，この標準に対してコンパイルするか，標準を定義する機能テスト・マクロを指定せずにコンパイルしたときにデフォルトによって， <limits.h>で有効になります。
<wchar.h>に定義されているマクロ WCHAR_MAX は， ISO C Amendment 1 では必要ですが，XPG4 では必要ありません。したがって次のようになります。
- ISO C Amendment 1 に準拠してコンパイルすると，このシンボルは有効になりますが， XPG4 に準拠してコンパイルしても有効になりません。
- ISO C Amendment 1 と XPG4 の両方に準拠してコンパイルすると，このシンボルは有効になります。
同様に， <wchar.h>内の関数 wcsftimeと wcstokの定義は，ISO C Amendment 1 と XPG4 で少し異なります。
- ISO C Amendment 1 に準拠するようにコンパイルすると， ISO C Amendment 1 プロトタイプが有効になります。
- XPG4 に準拠するようにコンパイルすると，XPG4 プロトタイプが有効になります。
- ISO C Amendment 1 と XPG4 の両方に準拠するようにコンパイルすると，このコンパイル・モードで発生した競合は ISO C を優先して解決されるため， ISO C プロトタイプが選択されます。
- 標準を選択する機能テスト・マクロを指定せずにコンパイルした場合は， ISO C Amendment 1 の機能が有効になります。
この例では，標準を選択する機能テスト・マクロを指定せずにコンパイルすると， wcsftimeと wcstokに対して WCHAR_MAXおよび ISO C Amendment 1 プロトタイプが有効になります。
wcswidth関数と wcwidth関数は， ISO C Amendment 1 に対する XPG4 の拡張機能です。これらのプロトタイプは <wchar.h>にあります。
これらのシンボルは，次の場合に有効になります。
- _XOPEN_SOURCEまたは _XOPEN_SOURCE_EXTENDEDを定義することにより， XPG4 に準拠するようにコンパイルした場合。
- DEC C バージョン 4.0 との互換性を維持してコンパイルするか，または OpenVMS バージョン 7.0 より前のシステムでコンパイルした場合。
- 標準を選択する機能テスト・マクロを指定せずにコンパイルした場合。
- ISO C Amendment 1 と XPG4 の両方に準拠するようにコンパイルした場合 ( これらのシンボルは ISO C Amendment 1 に対する XPG4 の拡張機能であるため)。
厳密な ISO C Amendment 1 モードでコンパイルしても，これらは有効になりません。

1.5.4 複数バージョン・サポート・マクロ

デフォルト設定では，ヘッダ・ファイルは，コンパイルが行われるオペレーティング・システムのバージョンによって提供される HP C RTL 内の API を有効にします。この処理は，『HP C User's Guide for OpenVMS Systems』に説明しているように， __VMS_VERマクロの定義済み設定によって行われます。たとえば，OpenVMS バージョン 6.2 でコンパイルすると，バージョン 6.2 およびそれより前のバージョンの HP C RTL API だけが使用可能になります。

__VMS_VERマクロの別の使用例として， OpenVMS Alpha バージョン 7.0 以降で提供される HP C RTL 関数の 64 ビット・バージョンのサポートがあります。すべてのヘッダ・ファイルで，64 ビットをサポートする関数は， __VMS_VERが OpenVMS バージョン 7.0 以降であることを示す場合にだけ有効になるように条件化されています。

オペレーティング・システムの以前のバージョンを対象にするには，次の操作を行います。

DECC$SHR の古いバージョンを指すように論理名 DECC$SHR を定義します。コンパイラは DECC$SHR のテーブルを使用してルーチン名に接頭語を付ける処理を実行します。
/DEFINE 修飾子を使用するか， #undefと #defineプリプロセッサ・ディレクティブの組み合わせを使用して， __VMS_VERを適切に定義します。/DEFINE 修飾子を使用する場合は，定義済みマクロの再定義に関する警告を無効にする必要があるかもしれません。

オペレーティング・システムの新しいバージョンを対象にする操作は，常に可能なわけではありません。一部のバージョンでは，まだ存在しないオペレーティング・システムの新機能が新しい DECC$SHR.EXE で要求されることがあります。このようなバージョンでは，ステップ 1 で論理名 DECC$SHR を定義すると，コンパイル・エラーになります。

__VMS_VERの値を上書きするには，コンパイラのコマンド・ラインで __VMS_VER_OVERRIDEを定義します。値を指定せずに __VMS_VER_OVERRIDEを定義すると， __VMS_VERは最大値に設定されます。

1.5.5 互換性モード

次の定義済みマクロは，DEC C の以前のバージョンまたは OpenVMS オペレーティング・システムの以前のバージョンとのヘッダ・ファイルの互換性を選択するために使用します。

_DECC_V4_SOURCE
_VMS_V6_SOURCE

ヘッダ・ファイルでは，次の 2 種類の非互換性を制御できます。

標準に準拠するために行う一部の変更では，ソース・コード・レベルの互換性が維持されませんが，バイナリ・レベルの互換性は維持されます。 DEC C バージョン 4.0 のソース互換性を選択するには， _DECC_V4_SOURCEマクロを使用します。
標準に準拠するためのその他の変更では，バイナリまたは実行時の非互換性が発生します。
一般に，プログラムを再コンパイルすると，新しい動作が実行されるようになります。このような場合は， _VMS_V6_SOURCE機能テスト・マクロを使用して，以前の動作を保持します。
しかし， exit， kill， wait関数の場合，これらのルーチンを ISO POSIX-1 準拠にするための OpenVMS バージョン 7.0 での変更は，デフォルトにするにはあまりに互換性がないと解釈されました。したがって，これらの場合は，デフォルトの動作は OpenVMS バージョン 7.0 より前のバージョンのシステムと同じです。 ISO POSIX-1 に準拠したこれらのルーチンのバージョンにアクセスするには， _POSIX_EXIT機能テスト・マクロを使用します。

次の例はこれらのマクロの使い方を理解するのに役立ちます。

ISO POSIX-1 標準に準拠するために，次のものに対する typedefが <types.h>に追加されました。
dev_t off_t gid_t pid_t ino_t size_t mode_t ssize_t nlink_t uid_t
DEC C バージョン 5.2 より前のバージョンを使用する古い開発環境では， <types.h>にこれらの typedefがないため，別のモジュールにこれらの定義を追加する必要があるかもしれません。このような場合は，DEC C バージョン 5.2 で提供される <types.h>を使用してコンパイルすると，コンパイル・エラーが発生する可能性があります。
現在の環境を維持し， DEC C バージョン 5.2 の <types.h>を取り込むには， _DECC_V4_SOURCEを定義してコンパイルします。このようにすると， DEC C バージョン 5.2 のヘッダから互換性のない参照が排除されます。たとえば， <types.h>では，前に示した typedefsは有効になりません。
OpenVMS バージョン 7.0 では， HP C RTL の getuid関数と geteuid関数は， UIC のグループの部分とメンバの部分の両方を含む OpenVMS UIC (ユーザ識別コード) を返すように定義されています。 DEC C RTL の以前のバージョンでは，これらの関数は UIC コードのメンバ番号だけを返していました。
<unistd.h>(ISO POSIX-1 標準で要求) および <unixlib.h>( HP C RTL 互換性の場合) 内の getuidと geteuidのプロトタイプは変更されていません。デフォルト設定では， getuidと geteuidを呼び出すプログラムを新たにコンパイルすると，新しい定義が使用されます。つまり，これらの関数は OpenVMS の UIC を返します。
プログラムで getuidと geteuidに関して， OpenVMS バージョン 7.0 より前のバージョンの動作を保持したい場合は， _VMS_V6_SOURCE機能テスト・マクロを定義してコンパイルします。
OpenVMS バージョン 7.0 では， HP C RTL の exit関数は ISO POSIX-1 のセマンティックで定義されています。この結果， exitに対する入力状態引数は 0～255 の値になります ( これより前のバージョンでは， exitは状態パラメータで OpenVMS の条件コードを受け付けることができました )。
デフォルトでは，OpenVMS システムの exit関数の動作は以前と同じです。つまり， exitは OpenVMS の条件コードを受け付けます。 ISO POSIX-1 と互換性のある exit関数を有効にするには， _POSIX_EXIT機能テスト・マクロを定義してコンパイルします。

前へ次へ目次索引