sigactionシステムコール

Question

私はsigactionのmanページを見ていました。私は次の行を見て終わりました。

sigaction(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE 

_POSIX_X_SOURCE、_X_OPEN_SOURCE、_POSIX_SOURCEは何を意味するのですか？それをどうしたらいいですか？ここで

Answer 1

は、機能マクロの男です：http://www.kernel.org/doc/man-pages/online/pages/man7/feature_test_macros.7.html

彼らは、ヘッダー内の標準サポートのいくつかのレベルまたはオフになります。

など。 _POSIX_C_SOURCE> = 1は、POSIX.2-1992以降をサポートする必要があることを意味します。 _X_OPEN_SOURCEは、POSIX.1、POSIX.2、およびXPG4が有効であることを意味します。マクロ（> = 500;> = 600;> = 700）の値が大きくなると、SUSv2 v3またはv4（UNIX 98; 03またはPOSIX.1-2008 + XSI）のいくつかの亜種も有効になります。 _POSIX_SOURCEは_POSIX_C_SOURCE = 1を定義する時代遅れの方法です

Answer 2

#defineは、プロトタイプを取得するためのもので、feature test macrosとして知られています。

は、例えば、次のコードはsusscessfully sigactionのプロトタイプを定義する：

#define _XOPEN_SOURCE 
#include <signal.h> 

は#define（等）が、プロトタイプを定義しないことなしsignal.hを含めます。

Answer 3

なお、「機能テストマクロ」と呼ばれるシンボルがヘッダに含まれるかもしれないシンボルの可視性を制御するために使用されるFeature test macro.

あります。実装、IEEE Std 1003.1-2001の将来のバージョン、およびその他の標準では、追加の機能テストマクロを定義する場合があります。

Answer 4

これらは機能テストマクロです。その目的は、プログラムがシステムヘッダーファイルにどの標準規格に準拠しようとしているのか、そしてどの拡張機能を使用したいのかをシステムに知らせることです。

機能テストマクロが定義されていないと、マクロでどのマクロ、関数、およびタイプ定義がヘッダーに表示されるかは実装によって大きく異なります。一般的には、のすべてをにすることが問題になります。「すべて」はあまり具体的ではないため、プログラムで使用されているシンボル名が拡張機能の一部と衝突する可能性があります。たとえ彼らが今でも衝突していなくても、将来どうなるかは分かりません。標準（ISO CやPOSIXなど）では、実装に厳密な要件があり、明示的に定義されていないか、標準で予約されていない名前でアプリケーションの名前空間が汚染されることはありません。機能テストマクロを使用して特定の標準を要求するときは、（1）この標準で定義されているものすべてを提供すること、（2）アプリケーションの名前空間を汚染しないこと、その標準。

正しいプログラムは、書き込まれた標準の正しい機能テストマクロを常に明示的に使用する必要があります。これを行う最も簡単な方法は、コンパイラコマンドライン（CFLAGS）に正しい-D引数を入れることです。各ソースファイルの最初の行に#defineを追加することもできます。任意のシステムヘッダがが含まれる前に

1. 機能検査マクロがトップで定義する必要があります：あなたががソースファイルでそれを行う場合は注意してください。
2. 異なる機能テストマクロを異なる翻訳単位で使用することは、通常はお勧めできません。余談として

、それは他の機能検査マクロと全く同じではないのですが、Linux/glibcの上に構築されたときに、すべての近代的なプログラムがoff_tが大きなファイルをサポートするために、64ビットであることを要求する_FILE_OFFSET_BITS=64を定義する必要があります。