除了不关闭评论
/*...
,什么构成了C中的词法错误?
这里有一些:
"abc<EOF>
EOF 是文件的结尾。事实上,很多词位中间的 EOF 应该会产生错误:
0x<EOF>
我假设在字符串中使用错误的转义符是非法的:
"ab\qcd"
浮点指数可能有问题
1e+%
可以说,你不应该在预处理器指令的末尾有东西:
#if x %
基本上任何不符合 ISO C 9899/1999,附件 A.1“词法语法”的东西都是词法错误,如果编译器根据这个语法进行词法分析。这里有一些例子:
"abc<EOF> // invalid string literal (from Ira Baxter's answer) (ISO C 9899/1999 6.4.4.5)
'a<EOF> // invalid char literal (6.4.4.4)
EOF 是文件的末尾。
double a = 1e*3; // misguided floating point literal (6.4.4.2)
int a = 0x0g; // invalid integer hex literal (6.4.4.1)
int a = 09; // invalid octal literal (6.4.4.1)
char a = 'aa'; // too long char literal (from Joel's answer, 6.4.4.4)
double a = 0x1p1q; // invalid hexadecimal floating point constant (6.4.4.2)
// instead of q, only a float suffix, that is 'f', 'l', 'F' or 'L' is allowed.
// invalid header name (6.4.7)
#include <<a.h>
#include ""a.h"
如果将 [@$`] 和其他类似的符号(可能来自 Unicode)放在字符串或注释之外的任何地方,C 语言中不会出现词法错误吗?
它们不构成该语言的任何有效词汇序列。它们无法通过词法分析器,因为词法分析器无法将它们识别为任何类型的有效标记。通常词法分析器是 FSMs 或基于正则表达式的,所以这些符号只是无法识别的输入。
例如下面的代码中有几个词法错误:
int main(void){
` int a = 3;
@ —
return 0;
}
我们可以通过将其提供给 gcc 来支持它,从而提供
../a.c: In function ‘main’:
../a.c:2: error: stray ‘`’ in program
../a.c:3: error: stray ‘@’ in program
../a.c:3: error: stray ‘\342’ in program
../a.c:3: error: stray ‘\200’ in program
../a.c:3: error: stray ‘\224’ in program
GCC 很聪明并且可以进行错误恢复,所以它解析了一个函数定义(它知道我们在 'main' 中),但这些错误肯定看起来像词法错误。它们不是语法错误,这是正确的。 GCC 的词法分析器没有可以从这些符号构建的任何类型的标记。请注意,它甚至将一个三字节的 UTF-8 符号视为三个无法识别的符号。
非法身份证
int 3d = 1;
非法预处理器指令
#define x 1
意外的令牌
if [0] {}
无法解析的id
while (0) {}
错误的浮动常量(例如
123.34e
,或123.45.33
)。
词汇错误:
0xe-2
,它看起来像一个表达式,但实际上根据标准是一个语法错误——一个奇怪的角落案例,由 pp-tokens 的规则产生。