利用 Visual Studio Code 寫 C/C++ 程式時，發現一些系統定義或是函數被畫了無法識別的紅色波浪 (red squiggly line) 在下面，但是真的編譯程式又會過。
原因是那些定義被放在 feature test macros (FTM) 的後面，當沒有特別給像是 -ansi, -std=c17 之類的參數時 gcc 預設會定義 _DEFAULT_SOURCE 巨集，因此編譯可以順利進行。但是 vscode 的解析器似乎是比照給了 -std=c17 之類的參數，因此這些 Linux 上特有的常數或函數定義就不會被抓到。
解決方法就是在 .vscode/c_cpp_properties.json 的 defines 區塊中，加上 _DEFAULT_SOURCE=1 或是 _XOPEN_SOURCE=700 來把 Linux 上的常數或函數定義納入。或是，為求慎重的話，也可以看函數的 man page 裡面所描述的 feature test macros 需求，來決定要怎麼設定。
Ref:
在編譯時 (嚴格說來是前處理的階段) 除了使用 -I 指定額外的標頭檔資料夾路徑之外，還有 -iquote,
-isystem, -idirafter 可以使用。
利用 -iquote 指定的資料夾路徑，只會在使用 #include "..." (quote form) 型式的引入中被參考，對使用 #include <...> 型式的引入沒有作用。
使用 -I, -isystem, -idirafter 這三種參數指定的資料夾路徑，則會對 #include "..." 與 #include <...> 型式的引入參考皆有影響。
透過 -isystem 指定的資料夾路徑下的標頭檔會被視為 system header 來處理，會有一些特殊待遇。
特殊待遇看起來主要是在警告訊息的處理上，被視為 system header 的標頭檔所產生的警告訊息中，除了特別利用 #warning 所產生的之外，其他都會被抑制掉。
在 GCC 的文件中有提到，利用 -isystem 與 -idirafter 引入的標頭檔都會被視為 system header 來處理，不過在 Clang 的文件中則是只有提到 -isystem 的部份。
這些選項在 GCC 跟 Clang 都有支援，行為看起來大致上是一樣的。
在搜尋順序上，目前只看到 GCC 文件有明確的說是以下的順序，不過 Clang 應該是一樣的:
#include "..." 型式) 檔案所在的資料夾路徑#include "..." 型式) -iquote 指定的資料夾路徑-I 指定的資料夾路徑-isystem 指定的資料夾路徑-idirafter 指定的資料夾路徑Reference: