以下是一些：

"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中不是词法错误吗？
它们不构成该语言的任何有效的词汇序列。它们不能通过lexer，因为lexer不能将它们识别为任何类型的有效标记。通常lexer是基于FSMs或regex的，所以这些符号只是无法识别的输入。
例如，在下面的代码中有几个词法错误：

int main(void){
` int a = 3;
@ —
return 0;
}

我们可以通过将其提供给gcc来支持它，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的lexer没有任何类型的标记可以从这些符号构建。请注意，它甚至将三字节UTF-8符号视为三个无法识别的符号。

非法id

int 3d = 1;

非法的预处理程序指令

#define x 1

意外标记

if [0] {}

无法解析的id

while (0) {}

浮点常数的错误形式（例如123.34e或123.45.33）。

词法错误：
1.未终止的注解
1.不是有效预处理器标记的任何非注解和非空格字符序列
1.不是有效C标记的任何预处理器标记;一个例子是0xe-2，它看起来像一个表达式，但实际上是一个根据标准的语法错误-一个由PP令牌规则产生的奇怪的角落情况。