ANSI C への移行

1

-Xa

(a = ANSI)　ANSI C に加えて K&R C との互換性を持たせます。ただし ANSI C による意味上の変更を受けます。K&R C と ANSI C が同じ構造の文に対して異なる意味を持つ場合、コンパイラはこの不一致について警告し、ANSI C の解釈を採用します。これは、デフォルトモードです。

(c = conformance)　K&R C との互換性を維持せず、ANSI C に最大限に準拠します。コンパイラは ANSI C に従わない構造を持つプログラムに対してエラーメッセージや警告メッセージを発行します。

(s = K&R C)　コンパイルされた言語には (ANSI 以前の) K&R C と互換性のあるすべての機能が含まれます。コンピュータは ANSI C と K&R C で異なる動作をするすべての言語構造について警告します。

(t = transition)　ANSI C に加えて K&R C との互換性を持たせます。ANSI C による意味上の変更を受けません。K&R C と ANSI C が同じ構造の文に対して異なる意味を持った場合、コンパイラはこの不一致について警告し、K&R C の解釈を採用します。

新規コードの作成

あるスコープ内に、 1 つのオブジェクトや関数に対して互換性を持たない 2 つの宣言が存在すると、ANSI C に準拠するコンパイラは常に診断を発行します。すべての関数がプロトタイプで宣言および定義されていて、該当するヘッダーファイルが正しいソースファイルにインクルードされていると、呼び出しはすべて関数の定義と一致します。これにより、最も多い C プログラミング上のミスの 1 つをなくすことができます。

既存コードの更新

1. 変更せずに再コンパイルする。

コーディングの変更がなくても、コンパイラは -v オプションで呼び出されると引数の型と数における不一致について警告します。

2. ヘッダーファイルだけに関数プロトタイプを追加する。

大域関数に対するすべての呼び出しが対象になります。

3. 関数プロトタイプをヘッダーファイルに追加し、ソースファイルをその局所 (静的) 関数に対する関数プロトタイプで始める。

関数に対するすべての呼び出しが対象になりますが、これには各局所関数に対するインタフェースをソースファイルに 2 度入力することが必要です。

4. すべての関数宣言と関数定義を変更して、関数プロトタイプを使用する。

混用に関する留意点

引数の数が可変する関数では、ANSI C の省略記号の表記と旧形式の varargs() 関数定義は混用できません。引数の数が固定した関数の場合は、以前の実装で渡されたとおり引数の型を指定するだけです。

K&R C ではデフォルトの引数拡張規則に従い、それぞれの引数は、呼び出された関数に渡される直前に変換されていました。これらの引数拡張では、int より短い整数型はすべて int サイズに拡張され、float 引数は double に拡張されるように指定しました。これにより、コンパイラとライブラリの両方が簡素化されました。関数プロトタイプはさらに表現力があるため、指定された型の引数が関数に渡されます。したがって、既存 (旧形式) の関数定義に対して関数プロトタイプを書く場合、以下のどの型を持つ関数プロトタイプにも引数があってはなりません。

char	signed char	unsigned char	float
short	signed short	unsigned short

プロトタイプを書く上での複雑な問題がまだ 2 つ残っています。1 つは typedef 名と、もう 1 つは短い符号なし型のための拡張規則です。

旧形式の関数の引数を off_t や ino_t といった typedef 名で宣言している場合は、typedef 名がデフォルトの引数拡張の対象となる型を指定しているかどうかを知ることが必要です。off_t は long 型なので関数プロトタイプで使用するのが適切です。しかし ino_t は unsigned short 型なので、関数プロトタイプで使用するとコンパイラが診断 (おそらくは致命的診断) を出すことになります。これは、旧形式の定義と関数プロトタイプが互換性を持たない別々のインタフェースを指定するためです。

もう 1 つの複雑な点は、unsigned short の代わりに何を使用するべきかということです。K&R C と ANSI C コンパイラの間で最も大きな違いは、unsigned char と unsigned short を int 値に拡張するための拡張規則です (16 ページの「拡張：符号なし保存と値保存」を参照してください)。このような旧形式の引数に一致する引数型は、コンパイルするときのコンパイラモードに依存します。-Xs と -Xt には unsigned int を、また -Xa と -Xc には int をそれぞれ使用します。

この場合は旧形式の定義を変更して int か unsigned int のどちらかを指定し、機能プロトタイプにおいて一致する型を使用することが最善と思われます (関数に入った後、必要に応じてより短い型を持つ局所変数にその値を代入することができます)。

プリプロセッサ (前処理系) の影響を受ける可能性のあるプロトタイプでの識別子の使用には注意してください。以下の例を考慮してください。

#define status 23 void my_exit(int status); /* 通常、スコープはプロトタイプから */ /* 始まり、プロトタイプで終わる。 */

短い型を含む旧形式の関数宣言と関数プロトタイプを混用しないでください。

void foo(unsigned char, unsigned short); void foo(i, j) unsigned char i; unsigned short j; {...}

__STDC__ を適切に使用すると、旧コンパイラと新コンパイラの両方に使用できるヘッダーファイルを生成できます。

header.h: struct s { /* . . . */ }; #ifdef __STDC__ void errmsg(int, ...); struct s *f(const char *); int g(void); #else void errmsg(); struct s *f(); int g(); #endif

次の関数はプロトタイプを使用していますが、旧システムでもコンパイルすることができます。

struct s * #ifdef __STDC__ f(const char *p) #else f(p) char *p; #endif { /* . . . */ }

以下に更新されたソースファイル (前述の更新方法 3 の場合) を示します。局所関数はまだ旧形式の定義を使用しますが、新しいコンパイラ用にプロトタイプが含まれています。

source.c: #include <header.h> typedef /* . . . */ MyType; #ifdef __STDC__ static void del(MyType *); /* . . . */ #endif static void del(p) MyType *p; { /* . . . */ } /* . . . */

引数の "..." 部分には名前がないので、stdarg.h に含まれる特別なマクロの組み合わせによって関数からのアクセスが可能になります。以前のバージョンでは、このような関数は varargs.h に含まれる同様のマクロを使用しなければなりませんでした。

書きたい関数が errmsg() というエラーハンドラで void を返し、唯一の固定引数がエラーメッセージの詳細を指定する int 型であると仮定します。この引数の後にはファイル名や行番号またはその両方と、エラーメッセージのテキストを指定する (printf() と同様の) 形式と引数を指定します。

これを以前のコンパイラでコンパイルするには、ANSI C コンパイラシステム専用に定義されるマクロ __STDC__ を使用します。したがって、適当なヘッダーファイルにおける関数の宣言は以下のようになります。

#ifdef __STDC__ void errmsg(int code, ...); #else void errmsg(); #endif

ここで複雑な点は、errmsg() の定義を含むファイルが旧形式と新形式の両方に存在するということです。まず先頭にヘッダーファイルをインクルードします。インクルードするべきヘッダーファイルは、コンパイラシステムに依存します。後で fprintf() と vfprintf() を呼び出すので、stdio.h もインクルードしています。

#ifdef __STDC__ #include <stdarg.h> #else #include <varargs.h> #endif #include <stdio.h>

次に来るのは関数の定義です。識別子の va_alist と va_dcl は旧形式の varargs.h インタフェースの一部です。

void #ifdef __STDC__ errmsg(int code, ...) #else errmsg(va_alist) va_dcl /* 注：セミコロンなし! */ #endif { /* 詳細は以下 */ }

旧形式の可変引数のしくみでは固定引数部分を指定できなかったので、可変部分の前に固定引数にアクセスするよう設定する必要があります。また、引数の "..." 部分に名前がないため、新しい va_start() マクロの 2 番目の引数には "..." の直前の引数名 (この例では code) を指定します。

拡張機能として、Sun ANSI C では以下のように固定引数なしで関数を宣言したり、定義することを許可しています。

int f(...);

va_start(ap,)

{
    va_list ap;
    char *fmt;
#ifdef __STDC__
    va_start(ap, code);
#else
    int code;

    va_start(ap);
    /* 固定引数を抽出する */
    code = va_arg(ap, int);
#endif
    if (code & FILENAME)
        (void)fprintf(stderr, "\"%s\": ", va_arg(ap, char *));
    if (code & LINENUMBER)
        (void)fprintf(stderr, "%d: ", va_arg(ap, int));
    if (code & WARNING)
        (void)fputs("warning: ", stderr);
    fmt = va_arg(ap, char *);
    (void)vfprintf(stderr, fmt, ap);
    va_end(ap);
}

va_arg() と va_end() マクロは、旧形式と ANSI C のどちらのバージョンに対しても同様に作用します。va_arg() は ap の値を変更するので、次の形式で vfprintf() を呼び出すことはできません。

(void)vfprintf(stderr, va_arg(ap, char *), ap);

FILENAME、LINENUMBER、WARNING といったマクロに対する定義は、通常 errmsg() の宣言と同じヘッダーファイルに含まれます。

たとえば errmsg() への呼び出しは、次のようにします。

errmsg(FILENAME, "<command line>", "cannot open: %s\n", argv[optind]);

静かなる変更

符号なし保存算術変換に依存するプログラムは、おそらく警告を出さず、異なる動作をします。これは現在広まっている慣行に対して委員会が行なった最も重大な変更であると考えられます。

背景

ほとんどの C コンパイラでは、さらに単純な規則、すなわち「符号なし保存」が使用されました。符号なし型を拡張する必要がある場合は、符号なし型に拡張されます。符号なし型と符号付き型が混在する場合、結果は符号なし型になります。

ANSI C により規定されたもう 1 つの規則は「値保存」というもので、結果の型はオペランドの型の相対的なサイズに依存します。unsigned char や unsigned short を拡張する場合、int が小さいほうの型のすべての値を表わすのに十分大きければ、結果の型は int になります。それ以外の場合、結果の型は unsigned int になります。値保存規則では、ほとんどの式について最も妥当な算術結果が得られます。

コンパイラ動作

例 1：キャストを使用する

int f(void)
{
    int i = -2;
    unsigned char uc = 1;

    return (i + uc) < 17;
}

この結果、-xtransition オプションを使用している場合は、コンパイラは次のような警告を出します。

line 6: 警告: ANSI C では "<" の意味が変わります。明示的なキャストを使用してください。

加算結果の型には、int (値保存) と unsigned int (符号なし保存) がありますが、ビットパターンはこれら 2 つの間で変化しません。2 の補数マシンでは、以下のようになります。

i: 111...110 (-2) + uc: 000...001 ( 1) =================== 111...111 (-1 または UINT_MAX)

このビット表現は int では -1 に、unsigned int では UINT_MAX に対応します。したがって、結果が int であれば符号付き比較が使用されて「より小さい」の評価は真になり、結果が unsigned int であれば符号なし比較が使用されて「より小さい」の評価は偽となります。

キャストを追加すると、2 つの動作のどちらを希望するかを指定するのに役立ちます。

値保存: (i + (int)uc) < 17 符号なし保存: (i + (unsigned int)uc) < 17

1 つのコードに対して受け取られる意味がコンパイラによって異なるため、この式はあいまいです。キャストの追加は、警告メッセージの削除と同じくらいユーザーにとって便利なものです。

ビットフィールド

キャストを同様に使用すれば、あいまいな状況をなくすことができます。

例 2：同じ結果になる

int f(void)
{
    unsigned short us;
    unsigned char uc;

    return uc < us;
}

この例では、自動的に int と unsigned int のどちらかに拡張されるので、比較は符号なしと符号付きのどちらで行われるか定まりません。しかし、これら 2 つの選択の結果は同一であるため、C コンパイラは警告を出しません。

整数定数

接尾辞なしの 10 進：

int、long、unsigned long

int、unsigned int、long、unsigned long

unsigned int、unsigned long

long、unsigned long

unsigned long

例 3：整数定数

int f(void)
{
    int i = 0;

    return i > 0xffff;
}

16 進定数の型は int (2 の補数マシンにおいて -1 という値を持つ) か、unsigned int (65535 という値を持つ) のどちらかなので、比較は -Xs と -Xt モードでは真となり、-Xa と -Xc モードでは偽となります。

ここでも以下のようにコードを適切なキャストによって明確にすれば、ANSI C コンパイラは警告を出さなくなります。

-Xt, -Xs モードで: i > (int)0xffff -Xa, -Xc モードで: i > (unsigned int)0xffff または i > 0xffffU

接尾辞文字 U は ANSI C の新しい機能であり、旧コンパイラではエラーメッセージが出ることがあります。

ANSI C 翻訳段階

1. ソースファイルにおけるすべての 3 文字表記シーケンスが置き換えられます。

ANSI C には 9 個の 3 文字表記シーケンスがあり、これらは欠陥のある文字セットの救済策としてのみ考案されたもので、ISO 646-1983 文字セットにない文字を表現する 3 文字の列です。

表 1-1 3 文字表記シーケンス

3 文字表記シーケンス	変換結果	3 文字表記シーケンス	変換結果
??=	#	??<	{
??-	~	??>	}
??(	[	??/	\
??)	]	??'	^
??!	|

これらのシーケンスは ANSI C コンパイラにより解釈されますが、使用されないことをお勧めします。ANSI C コンパイラでは、-xtransition オプションを使用していて、移行 (-Xt) モード中に 3 文字を置き換える場合 (注釈を含む) は、ユーザーに警告します。

/* comment *??/ /* still comment? */

この例では ??/ はバックスラッシュになります。この文字とその次の復帰改行 (newline) は削除されます。結果の文字は次のようになります。

/* comment */* still comment? */

2 行目の最初のスラッシュ (/) は注釈の終了記号です。次のトークンは * です。

2. すべてのバックスラッシュと復帰改行文字の組み合わせが削除されます。

3. ソースファイルは前処理トークンと空白シーケンスに変換されます。1 つの注釈行は 1 つのスペース文字に置き換えられます。

4. すべての前処理指令が処理され、マクロの置換が行われます。#include 指令は指定されたソースファイルに対して、その内容が指令行と置き換わる前に段階 1 〜 4 を実行します。

5. 文字定数と文字列リテラルにおけるすべてのエスケープシーケンスが解釈されます。

6. 隣接する文字列リテラルが連結されます。

7. すべての前処理トークンが通常のトークンに変換されます。コンパイラはこれらを正しく構文解析し、コードを生成します。

8. すべての外部オブジェクトと関数参照が解決され、最終的なプログラムになります。

前処理プログラム内でのトークン化プロセスにおいて、マクロ置換は文字単位 (トークン単位ではない) の操作として行われたので、トークンと空白は前処理中に非常に多くのバリエーションを持つことがありました。

これら 2 つの方法から生じる相違点は多数存在します。本節の残りの部分では、行の継ぎ合わせ、マクロ置換、マクロ置換中に起こる文字列化およびトークン貼付けにより、コードの動作がどのように変化するかについて述べています。

論理ソース行

マクロ置換

#define name (*name)

これにより、name の使用は name を通した間接的な参照に置換されます (旧 C プリプロセッサでは非常に多くの括弧とアスタリスクを生成し、結局マクロ再帰についてエラーを出すことになります)。

ANSI C により採用されたマクロ置換方法の大きな変更点は、(マクロ置換演算子の # と ## のオペランドであるマクロ引数以外の) マクロ引数が、置換トークンリストにおけるそれらの置換の前に再帰的に拡張されることです。ただしこの変更では、結果のトークンにおいて実際の相違点が生じることはほとんどありません。

文字列の使用方法

---

注 - ANSI C では、-xtransition オプションを使用している場合は、 で印した以下の例で、旧機能の使用に関する警告が出されます。移行モード (-Xt および -Xs) の場合のみ、結果は C の以前のバージョンの場合と同じになります。

---

#define str(a) "a!"            
str(x y)

プリプロセッサはマクロ引数に似た文字を文字列リテラル (文字定数) の中から検索しました。ANSI C ではこの機能の重要性を認めていましたが、トークンの操作については許可できませんでした。ANSI C では、上記マクロを呼び出すと文字列リテラル "a!" が生成されます。ANSI C で以前の効果を達成するには、文字列リテラルの連結とマクロ置換演算子 # を利用します。

#define str(a) #a "!" str(x y)

上記のコードでは、2 つの文字列リテラルの "x y" と "!" を生成し、連結後は旧バージョンと同じ "x y!" を生成します。

文字定数については、類似の操作をする直接的な置換方法はありません。この機能の主な使用方法は以下のようなものでした。

#define CNTL(ch) (037 & 'ch') CNTL(L)

この例では、以下が生成されました。

(037 & 'L')

これは ASCII の Control-L 文字とみなされます。現在における最善の解決方法は、このマクロのすべての使用方法を以下のように変更することです。

#define CNTL(ch) (037 & (ch)) CNTL('L')

このコードは式にも適用できるので、読みやすく役に立ちます。

トークンの貼り付け

#define self(a) a
#define glue(a,b) a/**/b 
self(x)1
glue(x,1)

ここでも、ANSI C はどちらの方法も許可していません。ANSI C では、上記のどちらの呼び出しでも x と 1 の 2 つのトークンが生成されます。上記の 2 つの方法のうち後者は、マクロ置換演算子の ## を使用することによって次のように ANSI C 用に書き直すことができます。

#define glue(a,b) a ## b glue(x, 1)

# と ## は、__STDC__ が定義されている場合にのみマクロ置換演算子として使用してください。## は実際の演算子なので、定義と呼び出しのどちらも空白の扱い方は自由です。

これら 2 種類の旧形式の貼付け方式のうち、前者は呼び出し時に貼付けの負担をかけるためほとんど使用されませんでした。

左辺値専用の型

派生型における型修飾子

const int five = 5;

これは const int 型を持つオブジェクトを宣言し、初期化します。この値はプログラムが正しければ変更されません (予約語の順序は C 言語にとって重要ではありません。たとえば、以下の 2 つの宣言は上記の宣言と事実上同一です)。

int const five = 5;

const five = 5;

次の宣言は const int へのポインタ型を持つオブジェクトを宣言し、このオブジェクトは直前に宣言したオブジェクトを最初に指します。

const int *pci = &five;

このポインタそのものは修飾された型を持っていません。ポインタは修飾された型を指し、プログラムの実行中にどの int でも指すように変更することができます。以下のようにキャストを使用しない限り、pci を使用してこのポインタが指すオブジェクトを変更することはできません。pci が実際に const オブジェクトを指す場合は、このコードの動作は未定義です。

*(int *)pci = 17;

以下の宣言は、int に対する const ポインタ型を持つ大域オブジェクトの定義が、プログラムのどこかに存在するということを表わしています。

extern int *const cpi;

この場合、cpi の値はプログラムが正しければ変更されませんが、それが指すオブジェクトを変更する際に使用することができます。const は上記の宣言中、* の後に来る点に注意してください。以下の一対の宣言は同じ効果があります。

typedef int *INT_PTR; extern const INT_PTR cpi;

これらの宣言は以下の宣言のように結合することができます。この場合、オブジェクトは const int に対する const ポインタ型を持つと宣言されています。

const int *const cpci;

const は "読み取り専用" を意味する

char *strcpy(char *, const char *);

さらに上の例で cpci の型は const int へのポインタであるにもかかわらず、それが指すオブジェクトの値を変更することができます (それが const int 型で宣言されたオブジェクトを実際に指していない場合に限ります)。

const の使用例

最初の使用方法では同じプログラムの他の並列呼び出し時にプログラムが使用するデータの一部を共有することができます。この不変のデータを変更しようとすると、そのデータがメモリーの読み取り専用部分に常駐しているために、ある種のメモリー保護違反によりすぐに検出されます。

2 番目の使用方法は、稼働中にメモリーアクセス違反を起こす前に、潜在的なエラーの場所を探し出すのに最も役立ちます。たとえば、文字列の中央に null 文字を一時的に挿入する関数に、そのように変更できない文字列へのポインタが渡されていると、コンパイル時に検出されます。

volatile

volatile の使用例

1. メモリーに配置された入出力ポートであるオブジェクト。

2. 複数の並列プロセス間で共有されるオブジェクト。

3. 非同期シグナルハンドラにより変更されるオブジェクト。

4. setjmp を呼び出し、その値が setjmp への呼び出しと対応する longjmp への呼び出しとの間で変更されるように宣言された自動記憶期間オブジェクト。

flag = 1;
while (flag)
    ;

それ以外の場合、flag の値はループの本体内では変更されないので、コンパイラは上記のループを flag の値を完全に無視する真の無限ループに変更してもかまいません。

4 番目の例はさらに複雑で、setjmp を呼び出す関数に局所的な変数を含みます。setjmp と longjmp の動作を詳細に調べてみると、4 番目の場合のオブジェクトの値については何の保証もないことがわかります。setjmp を呼び出す関数と longjmp を呼び出す関数との間のあらゆるスタックフレームを longjmp で調べて、退避されたレジスタ値を得るというのが最も望ましい動作です。スタックフレームは非同期的に生成されることがあるため、この操作がさらに困難なものになっています。

自動オブジェクトが volatile 修飾型で宣言されると、コンパイラはプログラマが書いた内容と完全に整合性のとれたコードを生成しなければならないことを認知します。したがって、そのような自動オブジェクトの最近の値は常にメモリーに入っており (レジスタではない)、longjmp が呼び出されたときは最新版であることが保証されます。

アジア言語での複数バイト文字の必要性

複数バイト文字という用語は ANSI C で定義され、どの符号化方式を採用するかにかかわらず、表意文字を符号化するバイトシーケンスを意味しています。すべての複数バイト文字は、いわゆる拡張文字セットのメンバーです (通常の単一バイト文字は複数バイト文字の特殊なケースにすぎません)。符号化に課せられた唯一の本質的な必要条件は、複数バイト文字はその一部に null 文字を使用できないということです。

ANSI C では、注釈、文字列リテラル、文字定数、およびヘッダーファイル名はすべて複数バイト文字のシーケンスであると規定しています。

符号化のバリエーション

もう 1 つは特殊なシフトバイトによって後のバイトの解釈が変わるものです。例としては、線を引くモードに出入りするために、いくつかの文字端末を使用している方法があります。シフト状態に依存する符号化方式の複数バイト文字で書かれたプログラムの場合、ANSI C ではそれぞれの注釈、文字列リテラル、文字定数、ヘッダーファイル名がシフトされていない状態で始まり、かつ終らなければなりません。

ワイド文字

それぞれのワイド文字ごとに対応する複数バイト文字があり、またその逆も成立します。通常の単一バイト文字に対応するワイド文字は、null 文字を含めてその単一バイト値と同じ値を持つことが必要です。ただし、EOF が char として表すことができないことがあるように、マクロ EOF の値を wchar_t に格納できるという保証はありません。

変換関数

これらの関数の動作は使用しているロケールによって変わります (56 ページの「setlocale() 関数」を参照してください)。

この市場をターゲットとしてコンパイラシステムを提供するベンダーは、さらに多くの文字列関連の関数を供給して、ワイド文字列の処理を簡単にすることが期待されます。しかし、ほとんどのアプリケーションプログラムでは、複数バイト文字をワイド文字に変換したり、その逆を行う必要はありません。たとえば diff のようなプログラムは複数バイト文字の読み込みと書き出しを行い、バイト単位での正確な一致についてチェックするだけです。正規表現のパターン一致を使用するさらに複雑な (grep のような) プログラムは複数バイト文字を理解する必要があるかもしれませんが、このような知識は正規表現を管理する関数の共通セットのみに必要です。プログラム grep 自身についていえば、他の特殊な複数バイト文字処理を必要としません。

C 言語機能

複数バイト文字は通常文字とワイド文字のどちらでも有効です。表意文字 'あ' を生成するために必要なバイトのシーケンスは符号化方式に固有ですが、それが 2 バイト以上で構成されている場合の文字定数 'あ' の値は、'ab' の値がそうであるように実装で定義されます。エスケープシーケンスを除き、通常の文字列リテラルは引用符間に指定されたバイトを持ち、それぞれの指定された複数バイト文字を含みます。

コンパイラがワイド文字定数またはワイド文字列リテラルを検出すると、それぞれの複数バイト文字は mbtowc() 関数を呼び出して行うかのようにワイド文字に変換されます。このように、L'あ' の型は wchar_t であり、"abcあxyz" の型は長さ 8 の wchar_t の配列です。通常の文字列リテラルの場合のように、それぞれのワイド文字列リテラルは余分なゼロ値要素を付け加えていますが、それは値ゼロを持つ wchar_t です。

通常の文字列リテラルが文字配列初期化のための簡単な方法として使用できるように、ワイド文字列リテラルは wchar_t 配列を初期化するのに使用できます。

wchar_t *wp = L"aあz"; wchar_t x[] = L"aあz"; wchar_t y[] = {L'a', L'あ', L'z', 0}; wchar_t z[] = {'a', L'あ', 'z', '\0'};

上記の例では、3 つの配列、x、y、z ならびに wp により指定された配列は同じ長さを持ち、すべて同一の値で初期化されます。

最後に、通常の文字列リテラルの場合のように、隣接するワイド文字列リテラルが連結されます。しかし、隣接する通常の文字列リテラルとワイド文字列リテラルとの連絡の結果は未定義です。このような連結を許可するかどうかは、コンパイラによって異なります。

本節では、予約名のさまざまなカテゴリと予約名を予約するための根拠について説明します。また、予約名なしにプログラムを制御できる規則についても説明します。

バランスプロセス

標準化以前には、予約語やヘッダーファイルの名前を自由に追加することができました。あるベンダーから別のベンダーの実装への移植だけでなく、あるリリースから別のリリースへの再コンパイルさえ保証できないことになります。

この結果 ANSI C 委員会では、すべての実装に対して特定の形式を持つ名前を除いて、余分な名前の使用を禁止しました。今日の C コンパイラシステムのほとんどに互換性があるのは、この決定によるものです。しかし、規格には 32 の予約語名と 250 ほどのヘッダーファイルの名前が含まれていますが、一定の命名規則に従っているわけではありません。

標準ヘッダーファイル

ほとんどの実装では上記以外のヘッダーファイルも備えていますが、厳密に ANSI 規格に従っている C プログラムではこれらのヘッダーファイルしか使用できません。

他の規格では、一部のヘッダーファイルの内容が一致しないことがあります。たとえば、POSIX (IEEE 1003.1) は、fdopen を stdio.h で宣言することを規定しています。これらの 2 つの規格が共存できるよう、POSIX はヘッダーファイルをインクルードする前にマクロ _POSIX_SOURCE を #define 文で定義して、追加したこれらの名前の存在を保証するよう求めています。X/Open も『Portability Guide』において拡張にこのマクロ方式を使用してきました。X/Open のマクロは _XOPEN_SOURCE です。

ANSI C では標準ヘッダーファイルが自己充足的で、「べき等的」であることが必要です。つまり、標準ヘッダーファイルはその前後に他のヘッダーファイルが組み込まれることを必要とせず、それぞれの標準ヘッダーファイルは問題なく 2 度以上インクルード可能です。規格では、ヘッダーファイルで使用される名前が変更されないことを保証するため、ヘッダーファイルを安全な状況でのみインクルードすることも求めています。

実装用に予約された名前

したがって規格では、実装で使用する可能性のあるすべての名前のサブセットを予約しています。これらは下線で始まり、別の下線あるいは大文字に続く識別子から成ります。つまり、この種の名前は次の正規表現に一致するすべての名前を含みます。

_[_A-Z][0-9_a-zA-Z]*

厳密に言えば、プログラムでこのような識別子を使用する場合の動作は未定義です。したがって、_POSIX_SOURCE (または _XOPEN_SOURCE) を使用するプログラムの動作は確定できません。

しかし、不確定の動作の程度はさまざまです。POSIX に適合した実装で _POSIX_SOURCE を使用する場合、ある名前を特定のヘッダーファイルに追加するとプログラムの不確定動作が生じることは判明していますが、プログラムはまだ規格に適合しています。ANSI C 規格におけるこういった意図的な抜け道により、実装は一見不適合と思われる仕様にも適合することができます。一方、POSIX 規格に準拠しない実装は、_POSIX_SOURCE のような名前を検出した場合にどのように動作してもかまいません。

規格は、下線で始まる他のすべての名前も予約しています。これらはヘッダーファイルの中 (ただし局所的なスコープを除く) で通常のファイルのスコープ識別子、もしくは構造体と共用体のためのタグとして使用されます。関数を _filbuf や _doprnt と名付けて、ライブラリの隠れた部分を実装するといった一般的な慣例が認められています。

拡張用に予約された名前

このリストでは、大文字から始まる名前はマクロで、関連するヘッダーファイルがインクルードされる場合のみ予約されます。残りの名前は関数を指定するので、大域オブジェクトまたは大域関数の名前としては使用できません。

使用できる名前

1. #include 文によって、すべてのシステムヘッダーファイルをソースファイルの最上部にインクルードする。_POSIX_SOURCE や _XOPEN_SOURCE、またはその両方の #define 文がある場合は例外で、その後に #include 文を挿入する。

2. 下線で始まる名前を定義または宣言してはいけない。

3. すべてのファイルをスコープとするタグと通常の名前の中で、最初の 2、3 文字内のどこかに下線または大文字を使用する (stdarg.h または varargs.h にある接頭辞 "va_" には注意してください)。

4. すべてのマクロ名の中で、最初の 2、3 文字内のどこかに大文字以外の文字または数字を使用する (errno.h がインクルードされている場合、E で始まるほとんどすべての名前は予約済みなので注意してください)。

ロケール

実用性と迅速化のため、ロケールはいくつかのカテゴリに分類されます。プログラムによってロケール全体を変更したり、1 つまたはいくつかのカテゴリだけを変更することもできます。一般に各カテゴリは、他のカテゴリに影響される関数との共通点がない関数の集合に影響を与えます。したがって、1 つのカテゴリを一時的に変更することにも意味があります。

setlocale() 関数

#include <locale.h>
/*...*/
setlocale(LC_ALL, "");

これによって、プログラムの現在のロケールが適切な国のものに変わります。これは LC_ALL が 1 カテゴリではなく、ロケール全体を指定するマクロだからです。標準カテゴリは、以下の表のとおりです。

LC_COLLATE	ソート情報
LC_CTYPE	文字分類情報
LC_MONETARY	通貨出力情報
LC_NUMERIC	数字出力情報
LC_TIME	日付と時刻の出力情報

特定のカテゴリを指定するために、マクロのうち任意のものを第 1 の引数として setlocale() に渡すことができます。

setlocale() 関数は、指定されたカテゴリ (または LC_ALL) に対する現ロケール名を返し、第 2 の引数が NULL ポインタであれば照会のみ行います。このようにして、以下のようなコードを使用し、ロケール全体またはその一部を一時的に変更することができます。

#include <locale.h> /*...*/ char *oloc; /*...*/ oloc = setlocale(カテゴリ, NULL); if (setlocale(カテゴリ, "ロケール") != 0) { /* 一時的に変更されたロケールを使用 */ (void)setlocale(カテゴリ, oloc); }

ほとんどのプログラムは、この機能を必要としません。

変更された関数

現ロケールの LC_CTYPE カテゴリが "C" 以外であれば、isdigit() と isxdigit() 以外の ctype.h 述語関数は、追加文字についてゼロ以外 (真) を返すことができます。ロケールがスペインの場合、isalpha('') は真です。同様に、tolower() や toupper() といった文字変換関数は、isalpha() 関数が認識する追加のアルファベット文字を適切に取り扱います。ctype.h 関数は通常、文字引数が指すテーブル参照を使用して実現されるマクロです。この関数の行動は、テーブルを新しいロケール値に設定し直すと変わるので、動作性能への影響はありません。

現ロケールの LC_NUMERIC カテゴリが "C" 以外であれば、印字可能の浮動小数値を書き込んだり解釈する関数は、ピリオド (.) 以外の小数点文字を使用するように変更することができます。任意の数値を 3 桁ごとの分離記号を付けたプリント可能形式に変換する機能はありません。プリント可能形式を内部形式に変換するとき、"C" ロケール以外ではそのような追加形式を受け入れる実装が可能です。小数点文字を使用する関数は printf() と scanf() の系列、atof()、strtod() です。実装時の定義により拡張が可能な関数は、atof()、atoi()、atol()、strtod()、strtol()、strtoul()、scanf() 系列です。

新しい関数

これらの他に、複数バイト関数 mblen()、mbtowc()、mbstowcs()、wctomb()、wcstombs() があります。

localeconv() 関数は、構造体を指すポインタを返します。その構造体の中には、現ロケールの LC_NUMERIC と LC_MONETARY カテゴリに対応した、数字と金額の書式作成に役立つ情報が含まれています (動作が 2 つ以上のカテゴリに依存する唯一の関数です)。数値については、構造体が小数点文字、3 桁ごとの分離記号、分離記号の位置を記述します。金額の書式を記述する構造体の要素は、他に 15 あります。

strcoll() 関数は、2 つの文字列が現ロケールの LC_COLLATE カテゴリに従って比較される以外は、strcmp() 関数と同様です。strxfrm() 関数を使用して文字列を変換し、変換後の 2 つの文字列を strcmp() に引き渡すと、strcoll() が変換前の 2 つの文字列を受け取ったときに返すものと同様の順序付けを行うことができます。

strftime() 関数は struct tm 中の値について、sprintf() で使用するものと同様の書式にし、現ロケールの LC_TIME カテゴリに従った日付と時刻の表記も行います。この関数は、UNIX System V リリース 3.2 の一部として提供された ascftime() 関数にもとづいています。

本節では C に関するこれら 2 つの定義の相違点を説明し、以下に示す式の文を例にとって、式の副作用であるグループ化と評価の相違点を示します。

int i, *p, f(void), g(void); /*...*/ i = *++p + f() + g();

定義

値を他の値や演算子と組み合わせることを式のグループ化と言います。上記の式のグループ化は、主に加算が行われる順に行われています。

結果の値を得るには、式の評価が必要です。式を評価するには、(その式の直前と直後の文の間のどこかで) 指定された副作用がすべて発生している必要があります。その結果指定の演算がグループ化に従って行われます。上記の式では、前の文とこの式の ; の間で、i と p が更新される必要があります。関数呼び出しは、どちらが先でも前の文の後、関数からの戻り値が使われる前であればいつでも出すことができます。特にメモリーを更新させる演算子は、その演算の値が使われる前に新しい値を設定する必要がないので注意してください。

K&R C での再配置の自由

i = { {*++p + f()} + g() };
i = { *++p + {f() + g()} };
i = { {*++p + g()} + f() };

K&R C の規則では、これらはすべて有効です。その上、式が以下のどちらの方法で書かれていた場合でもグループ化は有効です。

i = *++p + (f() + g()); i = (g() + *++p) + f();

オーバーフローが例外になるか、あるいはオーバーフローの前後の加算と減算が逆でないアーキテクチャでこの式が評価された場合、加算のどれかでオーバーフローになれば、3 通りのグループ化は異なった動きをします。

このようなアーキテクチャにおいて K&R C でこの式に使える唯一の救済策は、式を分割して特定のグループ化を強制することです。上記の 3 通りのグループ化を強制的に分割したものを以下に示します。

i = *++p; i += f(); i += g(); i = f(); i += g(); i += *++p; i = *++p; i += g(); i += f();

ANSI C の規則

i = { {*++p + f()} + g() };

ANSI C では、意図しないオーバーフローの対策として式を分割する必要はありません。

括弧の扱い

ANSI C の式では構文解析によって指定されるグループ化があるだけで、括弧は式の構文解析を助ける手段として使われます。通常の式の優先度と結合規則は、括弧とまったく同じ重みを持っています。

上記の式を次のように書き換えてもグループ化は変わらず、評価も変わりません。

i = (((*(++p)) + f()) + g());

as if 規則

• コンパイル時の定数の計算など、再配置により最適化できる部分が多い。

• ほとんどのマシンでは、再配置しても汎整数型の式の結果が変わらない。

• あらゆるマシンにおいて、ある種の演算は数学的にも算術的にも交換および結合することができる。

したがって、2 進数のビット単位の (シフトを除く) 演算子はすべて、どんなマシン上でも再配置することができます。これは再配置によるグループ化の変更に気付く方法がないからです。オーバーフローが自然に桁送りになる、普通の 2 の補数を基準とする装置では、同様の理由で乗算または加算を含む整数式を再配置することができます。

C 言語中でこのような変更が行われても、ほとんどの C プログラマにとって大きな影響はありません。

型

不完全型は 3 種類しかありません。void、長さ指定なしの配列、そして内容指定なしの構造体と共用体です。void 型は、完全化できない不完全型という点で他の 2 つとは異なります。この型は、関数の特殊な戻り値と引数の型として役立ちます。

不完全型を完全にする

不完全な構造体または共用体は、同じタグに関する同じスコープの中で、後に続く宣言で内容を指定することによって完全化されます。

宣言

• 不完全型を指すポインタ

• 不完全型を返す関数

• 関数の引数の不完全型

• 不完全型に関する typedef 名

配列と関数引数の型はポインタ型になるように書き直されるため、外見上不完全な配列引数型は、実際は不完全ではないことに注意してください。文字ポインタの長さを指定しない配列として、main の argv の典型的宣言 (すなわち char *argv[]) は、文字ポインタを指すポインタに書き直されます。

式

void *p

不完全型の必要性

struct a { struct b *bp; };
struct b { struct a *ap; };

なんらかの形のポインタと、異種データ型を持つ強力に型付けされたプログラム言語では、上記のような場合の処理方法を提供しています。

例

typedef struct item_tag Item;
typedef union note_tag Note;
typedef struct list_tag List;
    .  .  .
struct item_tag { . . . };
    .  .  .
struct list_tag {
    List *next; . . .
};

さらに、プログラムの他の部分に内容を利用させない構造体と共用体については、ヘッダーファイルは内容なしのタグを宣言することができます。プログラムの他の部分は、不完全な構造体または共用体を指すポインタを、メンバーを使う以外の目的で使用することができます。

よく使用される不完全型は、長さ指定なしの外部配列です。一般には、その内容を使用するために配列の長さを知る必要はありません。

多重宣言

分離コンパイルでの互換性

• 対応するスカラ (汎整数、浮動小数、ポインタ) 型には、同じソースファイルにあるような互換性が必要です。

• 対応する構造体、共用体、および列挙型はメンバーの数が同じであり、対応するそれぞれのメンバーは、ビットフィールド幅を含め (コンパイル間で) 互換型を持つ必要があります。

• 対応する構造体は、メンバーの順序が同じでなければなりません (共用体と列挙型は、メンバーの順序が違ってもかまいません)。

• 対応する列挙型は、メンバーの値が同じでなければなりません。

構造体、共用体、および列挙型では、(名前のないメンバーについては、名前がないことも含めて) メンバー名も対応する必要がありますが、それぞれのタグはその必要がありません。

互換型は再帰的に定義されます。その根底にあるのは、型を指定する予約語です (これらは、unsigned short は unsigned short int と同じであり、型指定のない型は int のある型と同じとする規則です)。他のすべての型は、派生してくる元の型が互換可能である場合にのみ互換性を持ちます。たとえば、2 つの修飾型は、修飾子 (const と volatile) が同一で、修飾子のない基本型が互換可能である場合は互換性を持ちます。

互換性のあるポインタ型

int *const cpi;
int *volatile vpi;

互換性のある配列型

互換性のある関数型

• 2 つの関数の型が互換性を持つには、戻り値の型が互換でなければなりません。2 つの関数の型の一方または両方にプロトタイプがある場合は、さらに複雑な規則になります。

• プロトタイプのある 2 つの関数の型が互換性を持つには、(省略記号 (...) の使用を含めて) 引数の数が同じで、対応する引数間に互換性がなければなりません。

• 旧形式の関数定義がプロトタイプのある関数の型と互換性を持つには、プロトタイプの引数が省略記号 (...) で終わらず、デフォルトの引数拡張を行なった後に、どのプロトタイプの引数にも、対応する旧形式の引数との互換性がなければなりません。

• 旧形式の関数宣言 (定義ではない) がプロトタイプのある関数の型と互換性を持つには、プロトタイプの引数が省略記号 (...) で終わらず、プロトタイプの引数すべての型が、デフォルトの引数拡張に左右されないものでなければなりません。

• 2 つの型が引数としての互換性を持つには、(トップレベルの) 修飾子があればそれを除去し、関数の型または配列の型が適切なポインタの型に変換された後に、両方の型が互換でなければなりません。

もう 1 つの興味深い点は、どの列挙型も汎整数型のどれかと互換性を持たなければならないことです。移植性のあるプログラムの場合、これは列挙型は独立した型であることを意味しています。通常、ANSI C 規格は列挙型をこのように扱います。

複合型