C言語/概念モデル

C言語の文法や機能を説明する時「翻訳フェーズ3」といった標準C規格で定義した用語が出てきます。

ここでは、ISO/IEC 9899:2018（通称 C18）の §5.1 Conceptual models（概念モデル）を抄訳/引用し解説します。

概念モデル

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1 Conceptual models：概念モデル.

翻訳環境

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.1 Translation environment：翻訳環境.

プログラム構成

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.1.1 Program structure：プログラム構成.

5.1 概念モデル( Conceptual models )

5.1.1 翻訳環境( Translation environment )

5.1.1.1 プログラム構成( Program structure )

1 C言語のプログラムは、すべてを一度に翻訳する必要はありません。 プログラムのテキストは、ソースファイルと呼ばれる単位で保管されています。この国際規格では、ソースファイル( source files )（またはプリプロセスファイル( preprocessing files )）と呼ばれる単位で保管されます。 ソースファイルは、前処理指令 #include によって含まれるすべてのヘッダーとソースファイルとともに、前処理翻訳単位( preprocessing translation unit )と呼ばれます。 前処理後の翻訳単位は、翻訳単位( translation unit )と呼ばれます。 以前に翻訳された翻訳単位は、個別に、またはライブラリとして保存することができます。 プログラムの各翻訳単位は、識別子が外部リンクされている関数の呼び出しや、識別子が外部リンクされているオブジェクトの操作、データファイルの操作などによって伝えます。 翻訳単位は別々に翻訳され、後にリンクされて実行可能なプログラムを生成することができます。

前方参照： 識別子の結合（linkages of identifiers 6.2.2）、外部定義（external definitions 6.9）、前処理指令（preprocessing directives 6.10）。

---

5.1 Conceptual models

5.1.1 Translation environment

5.1.1.1 Program structure

1 A C program need not all be translated at the same time. The text of the program is kept in units called source files, (or preprocessing files) in this International Standard. A source file together with all the headers and source files included via the preprocessing directive #include is known as a preprocessing translation unit. After preprocessing, a preprocessing translation unit is called a translation unit. Previously translated translation units may be preserved individually or in libraries. The separate translation units of a program communicate by (for example) calls to functions whose identifiers have external linkage, manipulation of objects whose identifiers have external linkage, or manipulation of data files. Translation units may be separately translated and then later linked to produce an executable program.

Forward references: linkages of identifiers (6.2.2), external definitions (6.9), preprocessing directives (6.10).

コンパイルという言葉こそ使っていませんが、「実行可能なプログラム( executable program )」について明言されているので、言語処理系はコンパイラとして実装されることが強く意識されています。

前処理翻訳単位( preprocessing translation unit )と翻訳単位( translation unit )は、規格の中で何度も出てきますが、

前処理翻訳単位

ソースファイル

拡張子

.c

翻訳単位

オブジェクトファイル

拡張子

.o .obj など

と一対一に考えることが出来ます。

翻訳フェーズ

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.1.2 Translation phases：翻訳フェーズ.

5.1.1.2 翻訳フェーズ( Translation phases )

1 翻訳の構文規則の中での優先順位は、以下のフェーズで規定されています)。

翻訳フェーズ1

物理的なソースファイルのマルチバイト文字は、必要に応じて、実装で定義された方法でソースの文字セットにマッピングされます（行末のインジケータのために改行文字を導入します）。

翻訳フェーズ2

物理的なソースラインを分割して論理的なソースラインを形成します。物理的なソースライン上の最後のバックスラッシュのみが、このようなスプライスの一部となる資格があります。空ではないソースファイルは改行文字で終わり、その前にバックスラッシュ文字があってはなりません。

翻訳フェーズ3

ソースファイルは，前処理トークン と空白文字の列（コメントを含む）に分解される。ソースファイルは部分的な前処理トークンや部分的なコメントで終わってはならない。各コメントは1つのスペース文字で置き換えられる。改行文字は保持されます。改行以外の空白文字の連続を保持するか、1つのスペース文字に置き換えるかは、実装で定義されます。

翻訳フェーズ4

前処理ディレクティブの実行、マクロの展開、_Pragmaの単項演算子の実行が行われます。国際文字名の構文に一致する文字列がトークン連結(6.10.3.3)によって生成された場合、その動作は未定義です。 ＃include前処理ディレクティブは、指定されたヘッダやソースファイルをフェーズ1からフェーズ4まで再帰的に処理します。その後、すべての前処理ディレクティブは削除されます。

翻訳フェーズ5

文字定数や文字列リテラルに含まれるソース文字セットの各メンバやエスケープシーケンスは、実行文字セットの対応するメンバに変換されます。対応するメンバがない場合は、ヌル（ワイド）文字以外の実装で定義されたメンバに変換されます。

翻訳フェーズ6

隣接する文字列リテラルのトークンは連結される。

翻訳フェーズ7

トークンを区切るホワイトスペースはもはや重要ではない。各前処理トークンはトークンに変換されます。得られたトークンは構文的、意味的に分析され、翻訳ユニットとして翻訳されます。

翻訳フェーズ8

外部のオブジェクトや関数の参照はすべて解決されます。 ライブラリのコンポーネントは外部の条件を満たすようにリンクされます。 ライブラリコンポーネントは、現在の翻訳で定義されていない関数やオブジェクトへの外部参照を満たすようにリンクされます。このようなトランスレータの出力はすべて、実行環境での実行に必要な情報を含んだプログラム イメージにまとめられます。

前方参照：国際文字名(universal character names 6.4.3)、字句要素(lexical elements 6.4)、前処理指令(preprocessing directives 6.10)、3文字表記(trigraph sequences 5.2.1.1)、外部定義(external definitions 6.9)。

註記：

---

5.1.1.2 Translation phases

1 The precedence among the syntax rules of translation is specified by the following phases.6)

1. Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary.Trigraph sequences are replaced by corresponding single-character internal representations.
2. Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines.Only the last backslash on any physical source line shall be eligible for being part of such a splice. A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character before any such splicing takes place.
3. The source file is decomposed into preprocessing tokens7) and sequences of white-space characters (including comments). A source file shall not end in a partial preprocessing token or in a partial comment. Each comment is replaced by one space character.New-line characters are retained.Whether each nonempty sequence of white-space characters other than new-line is retained or replaced by one space character is implementation-defined.
4. Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed.If a character sequence that matches the syntax of a universal character name is produced by token concatenation (6.10.3.3), the behavior is undefined.A #include preprocessing directive causes the named header or source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted.
5. Each source character set member and escape sequence in character constants and string literals is converted to the corresponding member of the execution character set; if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character.8)
6. Adjacent string literal tokens are concatenated.
7. White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token.The resulting tokens are syntactically and semantically analyzed and translated as a translation unit.
8. All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment.

Forward references: universal character names (6.4.3), lexical elements (6.4), preprocessing directives (6.10), trigraph sequences (5.2.1.1), external definitions (6.9).

Note

6)Implementations shall behave as if these separate phases occur, even though many are typically folded together in practice. Source files, translation units, and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation. The description is conceptual only, and does not specify any particular implementation.

7)As described in 6.4, the process of dividing a source file’s characters into preprocessing tokens is context-dependent. Forexample, see the handling of < within a #include preprocessing directive.

8)An implementation need not convert all non-corresponding source characters to the same execution character.

診断メッセージ

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.1.3 Diagnostics：診断メッセージ.

5.1.1.3 診断メッセージ( Diagnostics )

1. 適合する実装は、前処理翻訳単位または翻訳単位が何らかの構文規則または制約の違反を含む場合、たとえその動作が未定義または実装定義として明示的に指定されている場合であっても、少なくとも1つの診断メッセージ（実装定義の方法で識別される）を生成しなければならない。その他の状況では、診断メッセージを作成する必要はない。
2. EXAMPLE 実装は、翻訳単位の診断を発行することが要求される。

    char i;
    int i;
   

   なぜなら、この国際規格の文言で、ある構成要素に対する動作が、制約エラー( constraint error )と未定義の動作( undefined behavior )の両方であると記述されている場合、制約エラーが診断されなければならないからである。

---

1. A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined. Diagnostic messages need not be produced in other circumstances.
2. EXAMPLE An implementation is required to issue a diagnostic for the translation unit:

    char i;
    int i;
   

   because in those cases where wording in this International Standard describes the behavior for a construct as being both a constraint error and resulting in undefined behavior, the constraint error shall be diagnosed.

Diagnostics は <assert.h> の章題と同じですが、ここでは診断メッセージ（コンパイラの出すエラーやウォーニングのこと）を示しています。

 char i;
 int i;

は、字句解析・構文解析的には問題有りませんが、意味的には大問題ですね。

実行環境

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2 Execution environments：実行環境.

実行環境

5.1.2 実行環境( Execution environments )

実行環境は、フリースタンディング（freestanding）実行環境及びホスト（hosted）実行環境の2種類の2つが定義されています。どちらの場合も、プログラムの起動は プログラムの起動は，実行環境から指定されたC関数が呼び出されたときに行われる。静的保存期間を持つすべてのオブジェクトは、プログラム起動前に初期化（初期値に設定）されなければならない。このような初期化の方法とタイミングは特に規定されていない。プログラムの終了は、実行環境に制御を戻す。

前方参照：オブジェクトの保存期間（6.2.4）、初期化（6.7.9）。

フリースタンディング環境

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.1 Freestanding environment：フリースタンディング環境.

5.1.2.1 フリースタンディング環境( Freestanding environment )

フリースタンディング環境（オペレーティングシステムの恩恵を受けずにCプログラムを実行できる環境）では、プログラム起動時に呼び出される関数の名前と型は、実装で定義される。第4項で要求されている最小限のセット以外に、フリースタンディング・プログラムが利用できるライブラリ機能は、すべて実装で定義される。

フリースタンディング環境でのプログラム終了の効果は、実装で定義される。

ホスト型環境

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.2 Hosted environment：ホスト型環境.

5.1.2.2 ホスト型環境( Hosted environment )

ホスト環境は用意しなくてもよいが、ある場合は以下の仕様に準拠すること。

プログラム開始処理

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.2.1 Program startup：プログラム開始処理.

5.1.2.2.1 プログラム開始処理( Program startup )

プログラムの起動時に呼び出される関数の名前はmainです。実装では、この関数のプロトタイプを宣言しない。この関数は、返却値の型がintで、パラメータがない状態で定義されなければならない。

int main(void) { /* ... */ }

または2つのパラメータ（ここではargcとargvとしていますが、宣言された関数のローカルなものなので、どのような名前を使っても構いません）を持つものです。

int main(int argc, char *argv[]) { /* ... */ }

または同等のもの、またはその他の実装で定義された方法で行います。

宣言されている場合、主関数のパラメータは以下の制約に従わなければならない。

• argc の値は非負でなければならない。
• argv[argc]はヌルポインターとする。
• argcの値が0より大きい場合、配列メンバargv[0]～argv[argc-1]には、プログラムの起動前にホスト環境によって実装上定義された値が与えられた文字列へのポインタが格納される。この意図は、ホスト環境の他の場所からプログラム起動前に決定された情報をプログラムに供給することにある。ホスト環境が大文字と小文字の両方の文字を持つ文字列を供給できない場合、実装は文字列が小文字で受信されるようにしなければならない。
• argcの値が0より大きい場合、argv[0]が指す文字列はプログラム名を表す。ホスト環境からプログラム名が得られない場合、argv[0][0]はヌル文字とする。argc の値が 1 より大きい場合は、argv[1]～argv[argc-1]が指す文字列がプログラム仮引数を表す。
• 引数 argc, argv および argv 配列が指す文字列は、プログラムによって変更可能であり、プログラムの起動から終了までの間、最後に保存された値を保持する。

プログラムの実行

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.2.2 Program execution：プログラムの実行.

5.1.2.2.2 プログラムの実行( Program execution )

ホスト環境では、プログラムはライブラリ条項（第7項）に記述されたすべての関数、マクロ、型定義、オブジェクトを使用することができる。

プログラム終了処理

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.2.3 Program termination：プログラム終了処理.

5.1.2.2.3 プログラム終了処理( Program termination )

main 関数の返却値が int 型と互換性のある型である場合、main 関数の最初の呼び出しからの復帰は、 main 関数の返却値を引数にして exit 関数を呼び出すことと同等である。

前方参照：用語の定義（7.1.1）、exit関数（7.22.4.4）。

プログラムの実行

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.3 Program execution：プログラムの実行.

5.1.2.3 プログラムの実行( Program execution )

この国際規格の意味的記述は、最適化の問題が関係しない抽象的な機械の動作を記述している。

ボラタイルオブジェクトへのアクセス、オブジェクトの変更、ファイルの変更、またはこれらの操作を行う関数の呼び出しはすべて副作用（ side effect ）であり、浮動小数点演算の結果値に影響を与えます。このような浮動小数点の状態をサポートする実装は、それに対する変更を副作用とみなすことが要求されます。浮動小数点環境ライブラリ <fenv.h> は、これらの副作用が問題となる場合を示すためのプログラミング機能を提供し、その他の場合には実装を解放します。左辺値式( lvalue expression )の値の計算には、指定されたオブジェクトのアイデンティティーを決定することが含まれます。

sequenced before は、単一のスレッドで実行される評価間の非対称、推移的、対の関係であり、これらの評価間に部分的な順序を誘導する。任意の2つの評価AとBが与えられたとき、AがBの前に順序付けられている場合、Aの実行がBの実行よりも先に行われる（逆に、AがBの前に順序付けられている場合、BはAの後に順序付けられる）。AとBの評価は、AがBの前か後のどちらかに配列されているが、どちらかが特定されていない場合、不確定に配列されていることになる。式AとBの評価の間にシーケンスポイントがあるということは、Aに関連するすべての値の計算と副作用が、Bに関連するすべての値の計算と副作用の前にシーケンスされることを意味する（シーケンスポイントの概要は付属書Cに記載されている）。

抽象機械では、セマンティクスで指定されたとおりにすべての式が評価されます。実際の実装では、式の一部を評価する必要はありません。式の値が使用されず、必要な副作用（関数の呼び出しやボラタイルオブジェクトへのアクセスに起因するものを含む）が発生しないことが推測できる場合は、式の一部を評価する必要はありません。

シグナルの受信により抽象機械の処理が中断された場合、ロックフリー・アトミック・オブジェクトでもなく、volatile sig_atomic_t型でもないオブジェクトの値は、浮動小数点環境の状態と同様に不定となります。ハンドラによって変更されたロックフリー・アトミック・オブジェクトでもvolatile sig_atomic_t型でもないオブジェクトの値は、ハンドラの終了時に不定( indeterminate )となり、ハンドラによって変更されて元の状態に戻らなかった場合の浮動小数点環境の状態も不定となります。

適合する実装に対する最低限の要求事項は以下の通りです。

• ボラタイルオブジェクトへのアクセスは、抽象機械のルールに基づいて厳密に評価されます。
• プログラム終了時には、ファイルに書き込まれたすべてのデータは、抽象的なセマンティクスに従ってプログラムを実行した場合に生じる結果と同一でなければならない。
• これらの要求の意図は、プログラムが入力を待つ前にプロンプトメッセージが実際に表示されるように、バッファリングされていない出力またはラインバッファリングされた出力ができるだけ早く表示されることである。これが、プログラムの観察可能な動作である。

何がインタラクティブデバイスを構成するかは、実装で定義される。

抽象的なセマンティクスと実際のセマンティクスとの間のより厳密な対応は、各実装によって定義されるかもしれません。

例1 ある実装では、抽象的セマンティクスと実際のセマンティクスの間に一対一の対応を定義するかもしれない。

シーケンスポイントごとに、実際のオブジェクトの値が抽象的なセマンティクスで指定された値と一致するようにします。この場合、キーワード volatile は余計なものになります。

あるいは、翻訳単位の境界を越えて関数を呼び出す場合にのみ、実際のセマンティクスが抽象的なセマンティクスと一致するように、各翻訳単位内でさまざまな最適化を行う実装もあります。このような実装では、呼び出し元の関数と呼び出し先の関数が異なる翻訳単位にある場合、それぞれの関数エントリと関数リターンの時点で、すべての外部リンクされたオブジェクトと、そのポインタを介してアクセス可能なすべてのオブジェクトの値が、抽象的なセマンティクスと一致することになります。さらに、そのような関数エントリの各時点で、呼び出された関数のパラメータの値と、そこへのポインタを介してアクセス可能なすべてのオブジェクトの値は、抽象的なセマンティクスに一致します。このような実装では、シグナル機能によって起動される割込みサービス・ルーチンが参照するオブジェクトは、揮発性のストレージを明示的に指定する必要があり、また他の実装上の制限もあります。

例2

 char c1, c2;
 /* ... */
 c1 = c1 + c2;

「整数昇格」( integer promotions )では、抽象機械が各変数の値をintサイズに昇格させた後、2つのintを加算して合計を切り捨てる必要があります。2つの文字の足し算がオーバーフローせずに、あるいはオーバーフローを静かに折り返して正しい結果が得られるのであれば実際の実行では、同じ結果を得るだけでよく、場合によっては昇格を省略することもできます。

例3 同様に

 float f1, f2;
 double d;
 /* ... */
 f1 = f2 * d;

倍精度演算を使用した場合と同じ結果になることを実装で確認できる場合は、単精度演算を使用して乗算を実行することができます（例えば、dをdouble型の定数2.0で置き換えた場合など）。

例4 ワイドレジスタを採用した実装では、適切なセマンティクスを尊重するように注意する必要があります。値は、それがレジスタで表現されているか、メモリで表現されているかに関係なく、独立しています。例えば、レジスタを暗黙のうちにこぼして(implicit spilling)値を変えることは許されません。また、ストレージタイプの精度に合わせて丸めるためには、明示的なストアおよびロードが必要です。特に、キャストと代入は、指定された変換を行うことが要求される。

 double d1, d2;
 float f;
 d1 = f = expression;
 d2 = (float) expression;

d1とd2に割り当てられた値は、floatに変換されている必要があります。

例5 浮動小数点式の並べ替えは、範囲だけでなく精度にも制限があるため、しばしば制限されます。実装では、オーバーフローやアンダーフローがない場合でも、丸め誤差があるため、一般的に数学的な足し算や掛け算の連想ルール(associative rules)や、分配ルールを適用することができません。同様に、実装は一般的に、式を再編成するために10進数の定数を置き換えることはできません。次の断片では、実数の数学的規則によって提案される並べ替えは、しばしば有効ではありません（F.9参照）。

 double x, y, z;
 /* ... */
 x = (x * y) * z; // not equivalent to x *= y * z;
 z = (x - y) + y; // not equivalent to z = x;
 z = x + x * y;   // not equivalent to z = x * (1.0 + y);
 y = x / 5.0;     // not equivalent to y = x * 0.2;

15 例 6 式のグループ化の動作を説明するために、次のフラグメントでは

 int a, b;
 /* ... */
 a = a + 32760 + b + 5;

次と、と同じ動作をします。

 a = (((a + 32760) + b) + 5);

これらの演算子の連想性と優先順位に起因する。このように、和の結果(a + 32760)は次にbに加えられ、その結果は5に加えられ、aに割り当てられた値となります。その結果が5に加算され、aに割り当てられた値となります。オーバーフローが明示的なトラップを生成するマシンではトラップが発生し、int型で表現可能な値の範囲が[-32768, +32767]であるマシンでは、実装はこの式を次のように書き換えることはできません。

a = ((a + b) + 32765);

なぜなら、aとbの値がそれぞれ-32754と-15であった場合、a＋bの和はトラップを生むが、元の式はトラップを生まないからである。また、この式を次のように書き換えることもできない。

a = ((a + 32765) + b);

あるいは

a = (a + (b + 32765));

は、aとbの値がそれぞれ4と-8または-17と12だったかもしれないからです。しかし、オーバーフローが静かに何らかの値を生成し、正と負のオーバーフローがキャンセルされるマシンでは、上記の式文は、実装によって上記のどのように書き換えても同じ結果になります。

例7 式のグループ化は、その評価を完全には決定しない。

 #include <stdio.h>
 int sum;
 char *p;
 /* ... */
 sum = sum * 10 - ’0’ + (*p++ = getchar());

と書かれているように表現文がまとめられています。

sum = (((sum * 10) - ’0’) + ((*(p++)) = (getchar())));

しかし、p の実際の増加は、前のシーケンスポイントと次のシーケンスポイント（ ; ）の間のどの時点でも起こり得ます。また、getcharの呼び出しは、その戻り値が必要になる前のどの時点でも起こり得ます。

前方参照：式 (6.5)、型修飾子 (6.7.3)、文 (6.8)、浮動小数点環境 <fenv.h> (7.6)、signal関数 (7.14)、ファイル (7.21.3)。

マルチスレッドでの実行とデータレース

• N2176 C17 ballot ISO/IEC 9899:2017 §5.1.2.4 Multi-threaded executions and data races：マルチスレッドでの実行とデータレース.

この項は、ISO/IEC 9899:2011（通称 C11）で追加されたので、C99の和訳であるJIS X 3010 プログラム言語Ｃには該当する項はありません。

5.1.2.4 マルチスレッドでの実行とデータレース( Multi-threaded executions and data races )

環境考慮事項

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2 Environmental considerations：環境考慮事項.

5.2 環境考慮事項( Environmental considerations )

文字集合

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.1 Character sets：文字集合.

5.2.1 文字集合( Character sets )

3文字表記

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.1.1 Trigraph sequences：3文字表記.

5.2.1.1 3文字表記( Trigraph sequences )

多バイト文字

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.1.2 Multibyte characters：多バイト文字.

5.2.1.2 多バイト文字( Multibyte characters )

文字表示の意味

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.2 Character display semantics：文字表示の意味.

5.2.2 文字表示の意味( Character display semantics )

シグナル及び割込み

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.3 Signals and interrupts：シグナル及び割込み.

5.2.3 シグナル及び割込み( Signals and interrupts )

環境限界

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.4 Environmental limits：環境限界.

5.2.4 環境限界( Environmental limits )

翻訳限界

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.4.1 Translation limits：翻訳限界.

5.2.4.1 翻訳限界( Translation limits )

数量的限界

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.4.2 Numerical limits：数量的限.

5.2.4.2 数量的限界( Numerical limits )

整数型の大きさ<limits.h>

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.4.2.1 Sizes of integer types <limits.h>：整数型の大きさ<limits.h>.

5.2.4.2.1 整数型の大きさ<limits.h>( Sizes of integer types <limits.h> )

浮動小数点型の特性<float.h>

• N2176 C17 ballot ISO/IEC 9899:2017 §5.2.4.2.2 Characteristics of floating types <float.h>：浮動小数点型の特性<float.h>.

5.2.4.2.2 浮動小数点型の特性<float.h>( Characteristics of floating types <float.h> )

参考文献

• ISO/IEC 9899:2018(en) Information technology — Programming languages — C. ISO/IEC. (2018-07-05). https://www.iso.org/obp/ui/#iso:std:iso-iec:9899:ed-4:v1:en. 
• JIS X 3010 プログラム言語Ｃ（ISO/IEC 9899:1999の和訳）. 日本工業標準調査会（当時、現：日本産業標準調査会）. (2003-12-20).