我正在看sigaction的man頁面,最後我看了下面一行。sigaction系統調用
sigaction(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE
_POSIX_X_SOURCE,_X_OPEN_SOURCE,_POSIX_SOURCE是什麼意思?該怎麼辦?
我正在看sigaction的man頁面,最後我看了下面一行。sigaction系統調用
sigaction(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE
_POSIX_X_SOURCE,_X_OPEN_SOURCE,_POSIX_SOURCE是什麼意思?該怎麼辦?
下面是功能宏的人: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
他們是你得到原型的#define
的東西,並且被稱爲feature test macros。
例如,下面的代碼將susscessfully定義原型sigaction
:
#define _XOPEN_SOURCE
#include <signal.h>
包含signal.h
而不該#define
(或其他人)不會限定的原型。
符號稱爲「功能測試宏」被用來控制可能被包括在報頭符號的可見性。 IEEE Std 1003.1-2001的實現,未來版本和其他標準可定義附加的功能測試宏。
這些是功能測試宏。他們的目的是允許你的程序通知系統頭文件你希望它符合哪個標準,以及你想要什麼擴展。
如果沒有定義任何功能測試宏,那麼實現在它們的頭文件中顯示的宏,函數和類型定義中會有很大差異。通常的做法是使默認情況下的所有內容都可見,這是一個問題,因爲「everything」並不是非常具體,而且很可能程序中使用的符號名稱可能與某些擴展名衝突。即使他們現在不衝突,也無法知道他們將來是否會發生衝突。因此,標準(如ISO C和POSIX)對實現施加了嚴格的要求,它不污染應用程序名稱空間,標準中未明確定義或保留名稱。當您使用功能測試宏來請求特定標準時,您要求實現確保(1)它提供了本標準中定義的所有內容,(2)它不會通過提供未定義的任何內容來污染應用程序的名稱空間那個標準。
正確的程序應該總是明確地使用正確的功能測試宏來寫入它所寫的標準。最簡單的方法是在編譯器命令行上輸入正確的-D
參數(CFLAGS
)。將#define
作爲每個源文件的第一行添加也是可行的。請注意,如果你在源文件中做到這一點,但:
順便說一句,這是不完全一樣的其他功能測試宏,但是當建立在Linux/glibc的要求將off_t
是64位大文件支持所有現代的程序應該定義_FILE_OFFSET_BITS=64
。