为什么GCC没有在文件末尾生成任何关于换行符的警告？
来自C11 5.1.1.2翻译阶段
第2段：
..。不为空的源文件应以新行字符结尾，在进行任何此类剪接之前，不应在该字符之前立即加上反斜杠字符。
这意味着每个源文件必须以换行符结尾。
示例：
#include <stdio.h>
int main()
{
printf("Hello world\n");
return 0;
}上面使用clang prog.c -Wall -Wextra -std=gnu11 -pedantic命令在Clang上编译的示例。编译器生成以下警告：
prog.c:7:16: warning: no newline at end of file [-Wnewline-eof]
}
^没关系，因为源文件的末尾没有换行符。
使用gcc prog.c -Wall -Wextra -std=gnu11 -pedantic命令，在GCC上编写了上述程序。GCC不会产生任何警告或错误。
那么，为什么GCC不产生任何警告或错误呢？
回答 3
Stack Overflow用户
发布于 2017-11-22 08:35:36
有一个问题，新行没有很好的标准定义，因为不同的系统有不同的新行约定。但你是对的..。如果标准规定编译器必须在这种情况下发出警告，而gcc没有发出警告，则应该将其作为一个不遵守问题提交。
但我同意@supercat的回答，因为可以假定一个没有最终\n的文件可以安全地解释为一个正确分隔的文本文件，没有结尾的行.因为\n可以解释为行分隔符，而不是以行结尾的字符。如果此解释有效，则将一个空文件解析为一个空行文件，编译器解析它没有问题，在这种情况下不应该发出警告。同样的情况也适用于没有最终\n的任何文件，使用\n完成的文件应该被解释为一个n + 1行文件，并有一个额外的空行(恐怕这对C代码的含义没有任何影响)
这可能是你可能会得到的回应，以防你去gcc项目投诉，所以要谨慎，但不要犹豫，做它。
顺便说一句，您是否尝试过向编译器提供最终的\\字符(没有\n字符)，允许编译器插入最后的换行符来模拟正确定义的文件，但是预处理程序必须以特殊的形式处理\\字符后面的新行。在这种情况下，编译器应该发出一些内容，因为您不能在文件的最后一行之后继续。当最后一行在\\中结束时，Clang什么也不说(那是不符合的)，让我们看看gcc.(对不起，到目前为止我还不能接触gcc )
Stack Overflow用户
发布于 2017-11-21 13:09:57
第4条第2点界定了“应”一词的含义：
如果出现在约束或运行时约束之外的“应”或“不”要求被违反，则该行为是未定义的。
您引用的段落不在约束部分。因此，如果源文件没有以尾随换行符结尾，则程序具有未定义的行为。
不需要对未定义的行为进行诊断。编译器可以自由地做任何事情。GCC的开发人员可能已经决定让这个程序表现得好像最后有一个换行符，而不是用警告来打扰用户。
Stack Overflow用户
发布于 2017-11-21 20:19:31
标准没有指定存储在磁盘上的物理字节与组成C程序的逻辑字符之间的任何特定关系。例如，如果源字符集只使用代码0x00-0x7E，则符合规范的实现可能会说，任何行的第一个字符都将设置上位，而前面没有任何其他类型的分隔符。这样的实现将被要求表现为每行后面跟着换行符，即使源文件中不会出现换行符(我不认为实现需要允许完全空白的源行以与包含单个空白字符的行不同的方式表示)。
如果实现指定文本文件由由换行符分隔的多行组成，而N行文件将包含N-1换行符，则需要在文件中的最后一个字节后面有一个换行符。但是，如果实现指定所有有效的文本文件都以换行符结尾，则当给定无效的文本文件时，它将不承担任何义务。
注意，除其他外，在某些实现中，#include后面的第一行将连接到包含的文件末尾的不完整行，这是合理的。这种行为虽然古怪，但在某些情况下可能是有用的，而且可能有一些代码依赖于它。考虑到这种剪接，如果出乎意料，可能会产生本质上无限的后果，将行为保留为未定义的比尝试对可能发生的事情进行分类更简单。
https://stackoverflow.com/questions/47410876
复制相似问题
腾讯云开发者
