與#include指令尾隨字符

我在一個源文件與#include指令尾隨字符

#include <some_sys_header_file.h>"

一個表面上無害線將其掩埋與一羣的其他包括用雙引號（而不是尖括號），以使該寄生沒有發現雙引號。

編譯器（或更確切地說，預處理器）非常高興，包含了所需的文件，並跳過了其餘部分。

但是，當使用Artistic Style格式化文件時，雙引號引起混淆，字符串被錯誤地分割爲多行。

有沒有這樣的標準應該如何處理？

來源

2015-08-14 Roddy

你可以給我們這個源文件編譯/累的環境嗎？ –

在這種情況下'gcc'可能會發出一個或兩個警告。 – ameyCU

@SantoshA：Embarcadero C++ Builder 2010，它是：舊的，b：任意不符合標準的。但是我更關心根據標準應該發生什麼。 – Roddy

這是未定義的行爲。

C99說，在6.10，一個#include指令的形式

# include pp-tokens new-line

唯一PP-令牌開始與"是字符串文字（C99 6.4.5 字符串文本）和報頭 - 名稱用雙引號（C99 6.4.7 標題名稱）。但是，字符串文字不能包含未轉義的換行符，並且標題名稱不能包含換行符。獨立"也不能作爲標題名稱的一部分，因爲它不在<>（C99 6.4.7 標題名稱）內。什麼根據C99 6.4 詞彙元素剩下的就是

預處理令牌：
...
每個非空白字符不能是上述

一個

結合語義第3段

如果'或"字符與最後一個類別匹配，則行爲是未定義。

所以你可能會也可能不會得到診斷。

來源

2015-08-14 12:04:44 Jens

編寫標準時，有些編譯器在其參數#include（特別是其他地方沒有使用的角括號表單）上沒有使用正常的字符串解析邏輯。由於關閉角括號不應該被除空格之外的任何東西所覆蓋，因此編譯器只需擦除最後一個非whitepsace字符（應該是尖括號）而不檢查它是什麼，這是合法的，使用它之前的任何文件作爲文件名。編譯器可以認爲：

#include <stdio.h> Hey

作爲請求包含名爲stdio.h> He的文件。雖然該特定的行爲可能不是有用的，它可能假設有必要在使用>作爲路徑分隔符的環境中使用C，且因此這可能需要：

#include <graphlib>drawing.h>

由於包括意圖報頭之後的字符名稱可能會導致編譯器#include以外的文件，因爲這樣的文件可以做任何事情，包括非標準定義的指令被認爲是未定義的行爲。就個人而言，我認爲，如果一個附加的形式進行了標準化的語言將大大受益：

#include "literal1" "literal2" ["literal3", etc.]

與通常的方式應用字符串連接。我已經有過荒唐一長串的工作很多項目包括道路，需要對可能如果有可能被大大減輕地說：

#include "fooproject_directories.h" 
#include ACMEDIR "acme.h" 
#include IOSYSDIR "io.h"

等從而明確哪些文件被認爲是從哪裏加載。雖然這可能是一些代碼某處可能依靠的能力，說：

#include "this"file.h"

爲加載一個名爲this"file.h文件的手段，我認爲標準可以由具有這種治療適應這樣的事情被認爲是不規範的，要求任何實現都記錄這種非規範行爲，並且不要求嚴格合規的程序在這些非規範平臺上工作。

來源

2015-08-15 17:40:00 supercat

與#include指令尾隨字符

回答

相關問題