日本-日本語
≫  お問い合わせ

製品とサービス >  ソフトウェアとOS >  OpenVMS >  マニュアル

OpenVMS マニュアル


 

OpenVMS ドキュメント
ライブラリ

タイトルページ
目次
まえがき
第 1 章:はじめに
第 2 章:入出力について
第 3 章:文字/文字列/引数リスト関数
第 4 章:エラー処理とシグナル処理
第 5 章:サブプロセス関数
第 6 章:Curses画面管理関数とマクロ
第 7 章:算術関数
第 8 章:メモリ割り当て関数
第 9 章:システム関数
第 10 章:国際化ソフトウェアの開発
第 11 章:日付/時刻関数
第 12 章:シンボリックリンクとPOSIXパス名
付録 A:各OSバージョンでサポートする関数一覧
付録 B:非標準ヘッダに複製されているプロトタイプ
索引
PDF
OpenVMS ホーム

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


目次 索引



ライブラリに登録されている関数が使用するパラメータの数は同じではないため,関数プロトタイプの構文の記述は次の規則に従っています。

  • パラメータの数が可変である場合,反復記号 (...) を使用してそのことを示します。

  • パラメータの型が可変である場合,構文に型を示しません。

printfの構文記述について考えてみましょう。

#include <stdio.h> 
int printf(const char *format_specification, ...); 

printfの構文記述には, 1 つ以上の省略可能なパラメータを指定できることが示されています。 printfのパラメータに関する残りの情報は,関数の説明に示されています。

1.3.3 UNIX 形式のファイル指定

HP C RTL の関数やマクロでは,ファイルを操作することがよくあります。移植性に関する重大な問題の 1 つとして,各システムで使用されるファイル指定が異なるという問題があります。多くの C アプリケーションは UNIX システムとの間で移植されるため,すべてのコンパイラが UNIX システム・ファイル指定を読み込み,解釈できると便利です。

C プログラムを UNIX システムから OpenVMS システムに移植するのに役立つように,次のファイル指定変換関数が HP C RTL に用意されています。

  • decc$match_wild

  • decc$translate_vms

  • decc$fix_time

  • decc$to_vms

  • decc$from_vms

これらのファイル指定変換関数を HP C RTL に取り込むと, UNIX システム・ファイル指定を含む C プログラムを書き直す必要がなくなるという利点があります。 HP C は大部分の有効な UNIX システム・ファイル指定を OpenVMS ファイル指定に変換できます。

UNIX システムと OpenVMS システムのファイル指定の違いだけでなく, RTL がファイルにアクセスする方法の違いについても注意してください。たとえば,RTL は有効な OpenVMS ファイル指定と有効な大部分の UNIX ファイル指定をそれぞれ受け付けますが,この 2 つの組み合わせを受け付けることはできません。 表 1-1 は, UNIX システムと OpenVMS システムのファイル指定の区切り文字の違いを示しています。

表 1-1 UNIX と OpenVMS のファイル指定の区切り文字
説明 OpenVMS システム UNIX システム
ノード区切り文字 :: !/
デバイス区切り文字 : /
ディレクトリ・パス区切り文字 [ ] /
サブディレクトリ区切り文字 [ . ] /
ファイル拡張区切り文字 . .
ファイル・バージョン区切り文字 ; 適用されない

たとえば, 表 1-2 は, 2 つの有効な指定と 1 つの無効な指定の形式を示しています。

表 1-2 有効および無効な UNIX と OpenVMS のファイル指定
システム ファイル指定 有効/無効
OpenVMS BEATLE::DBA0:[MCCARTNEY]SONGS.LIS 有効
UNIX beatle!/usr1/mccartney/songs.lis 有効
     
--- BEATLE::DBA0:[MCCARTNEY.C]/songs.lis 無効

HP C がファイル指定を変換する場合, OpenVMS システムと UNIX システムの両方のファイル指定を検索します。したがって, HP C が UNIX システムのファイル指定を変換する方法と, UNIX システムが同じ UNIX ファイル指定を変換する方法には違いがあることがあります。

たとえば, 表 1-2 に示すように 2 種類のファイル指定の方法を組み合わせた場合, HP C RTL は [MCCARTNEY.C]/songs.lis を [MCCARTNEY]songs.lis または [C]songs.lis として解釈する可能性があります。したがって, HP C が複合ファイル指定を検出すると,エラーが発生します。

UNIX システムでは,デバイス名,ディレクトリ名,ファイル名に対して同じ区切り文字を使用します。このように UNIX ファイル指定にはあいまいさがあるため, HP C はユーザの期待どおりに有効な UNIX システムのファイル指定を変換できないことがあります。

たとえば, /bin/todayを OpenVMS システムの形式で表現すると, [BIN]TODAY または [BIN.TODAY] になります。 HP C は存在するファイルからだけ正しい解釈を行うことができます。ファイル指定で 1 つのファイルまたはディレクトリに対して UNIX システムのファイル名構文が使用されている場合,次の条件のいずれかが満たされれば,対応する OpenVMS のファイル名に変換されます。

  • 指定が既存の OpenVMS ディレクトリに対応する場合は,そのディレクトリ名に変換されます。たとえば,DEV:[DIR.SUB] が存在する場合は, /dev/dir/subは DEV:[DIR.SUB] に変換されます。

  • 指定が既存の OpenVMS ファイル名に対応する場合は,そのファイル名に変換されます。たとえば,DEV:[DIR]FILE が存在する場合は, /dev/dir/fileは DEV:[DIR]FILE に変換されます。

  • 指定が存在しない OpenVMS ファイル名に対応し,指定されたデバイスおよびディレクトリが存在する場合は,ファイル名に変換されます。たとえば,DEV:[DIR] が存在する場合は, /dev/dir/fileは DEV:[DIR]FILE に変換されます。

  注意
OpenVMS Version 7.3 以降,HP C RTL に対して, UNIX 形式のファイル指定の先頭の部分をサブディレクトリ名またはデバイス名として解釈することを要求できるようになりました。

以前のリリースと同様に, foo/bar(UNIX 形式の名前) のデフォルト変換は FOO:BAR (OpenVMS 形式のデバイス名) です。

foo/bar(UNIX 形式の名前) を [.FOO]BAR (OpenVMS 形式のサブディレクトリ名) に変換するように要求するには,論理名 DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION に ENABLE を定義します。 DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION はファイルごとにチェックされるのではなく,イメージを起動するときに 1 回だけチェックされます。この論理名の定義は, decc$to_vms関数に影響するだけでなく, UNIX 形式と OpenVMS 形式の両方のファイル名を引数として受け付けるすべての HP C RTL 関数に影響します。

UNIX システム環境では,数値のファイル記述子を使用してファイルを参照します。ファイル記述子の中には,標準 I/O デバイスを参照するものと,実際のファイルを参照するものがあります。ファイル記述子がオープンされていないファイルに属す場合は, HP C RTL はそのファイルをオープンします。 HP C は次の OpenVMS 論理名を使用してファイル記述子を評価します。

ファイル記述子 OpenVMS の論理名 意味
0 SYS$INPUT 標準入力
1 SYS$OUTPUT 標準出力
2 SYS$ERROR 標準エラー



1.3.4 拡張ファイル指定

ODS-5 ボリューム構造では,UNIX 形式と OpenVMS 形式が混在したファイル名のサポート機能が拡張されました。長いファイル名がサポートされるようになり,ファイル名でこれまでより広範囲にわたる文字を使用できるようになり,ファイル名で大文字と小文字の区別が保持されるようになりました。 OpenVMS Alpha Version 7.3-1 では, C RTL は ODS-5 文字のサポートを大幅に向上しており,これまでは 214 文字しかサポートされなかったのに対し, 256 文字中,250 文字をサポートするようになりました。また,ファイル・タイプのないファイル名にもアクセスできるようになりました。

新しいサポートを有効にするには, 1 つ以上の C RTL 機能論理名を定義する必要があります。これらの名前は次のとおりです。

DECC$EFS_CHARSET
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION
DECC$FILENAME_UNIX_NO_VERSION
DECC$FILENAME_UNIX_REPORT
DECC$READDIR_DROPDOTNOTYPE
DECC$RENAME_NO_INHERIT

これらの機能論理名や他の機能論理名の詳細については, 第 1.5 節 を参照してください。

1.3.5 シンボリック・リンクと POSIX パス名

OpenVMS では, Open Group 準拠のシンボリック・リンクと, POSIX パス名の処理をサポートしています。詳細は, 第 12 章 を参照してください。

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

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

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

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

  • 標準

  • 複数バージョンのサポート

  • 互換性



1.4.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.4.2 標準の選択

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

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

表 1-3 機能テスト・マクロ---標準
マクロ名 選択される標準 暗黙に選択される他の標準 説明
_XOPEN_SOURCE_EXTENDED XPG4 V2 XPG4,ISO POSIX-2,ISO POSIX-1,ANSI C 以前は X/Open で採用されていなかった従来の UNIX ベースのインタフェースも含めて, XPG4 拡張機能が有効になる。
_XOPEN_SOURCE XPG4 (X/Open Issue 4) ISO POSIX-2, ISO POSIX-1,ANSI C XPG4 標準シンボルが有効になり, _POSIX_C_SOURCE が 2 より大きい値に定義されていない場合は, 2 に設定される 1 2
_XOPEN_SOURCE=500 X/Open Issue 5 ISO POSIX-2,ISO POSIX-1,ANSI C X/Open Issue 5 標準シンボルが有効になり, _POSIX_C_SOURCE が 2 より大きい値に定義されていない場合は, 2 に設定される 1 2
_XOPEN_SOURCE=600 X/Open Issue 6 ISO POSIX-2,ISO POSIX-1,ANSI C X/Open Issue 6 標準シンボルが有効になり, _POSIX_C_SOURCE が 2 より大きい値に定義されていない場合は, 2 に設定される 1 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 標準のシンボルが有効になる。

1ISO 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 が優先される。
2XPG4 は ISO C Amendment 1 を拡張したものである。 _XOPEN_SOURCE または _XOPEN_SOURCE_EXTENDED を定義すると, ISO C API の他に,ヘッダ・ファイルで提供される XPG4 拡張機能も選択される。このコンパイル・モードでは,XPG4 拡張機能が有効になる。

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

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

1.4.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>内の関数 wcsftimewcstokの定義は,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 の機能が有効になります。


    この例では,標準を選択する機能テスト・マクロを指定せずにコンパイルすると, wcsftimewcstokに対して WCHAR_MAXおよび ISO C Amendment 1 プロトタイプが有効になります。

  • wcswidth関数と wcwidth関数は, ISO C Amendment 1 に対する XPG4 の拡張機能です。これらのプロトタイプは <wchar.h>にあります。
    これらのシンボルは,次の場合に有効になります。

    • _XOPEN_SOURCE または _XOPEN_SOURCE_EXTENDED を定義することにより, XPG4 に準拠するようにコンパイルした場合。

    • DEC C Version 4.0 との互換性を維持してコンパイルするか,または OpenVMS Version 7.0 より前のシステムでコンパイルした場合。

    • 標準を選択する機能テスト・マクロを指定せずにコンパイルした場合。

    • ISO C Amendment 1 と XPG4 の両方に準拠するようにコンパイルした場合 ( これらのシンボルは ISO C Amendment 1 に対する XPG4 の拡張機能であるため)。


    厳密な ISO C Amendment 1 モードでコンパイルしても,これらは有効になりません。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡