为什么 gcc 没有显示在变量名中使用 $ 的警告消息？答案

【问题标题】：Why is gcc not showing a warning message for using $ in a variable name?为什么 gcc 没有显示在变量名中使用 $ 的警告消息？
【发布时间】：2019-03-10 11:05:55
【问题描述】：

我是 C 的新手，我正在通过 Programming in C 第 4 版学习 C。斯蒂芬科坎。在第 29 页，他写道$ 不是变量名的有效字符。他使用的是 C11 标准。

我写了以下代码

#include <stdio.h>

int main (void)
{
    int a$ = 1;

    printf ("%i", a$);

    return 0;
}

并使用命令gcc -std=c11 -pedantic practice.c -o practice.o && ./practice.o 运行它。我的文件名是practice.c。

输出为1。编译器不应该给我使用$ 的警告吗？使用 $ 符号作为标识符不是 GCC 提供的扩展吗？

我在 Ubuntu 18.10 中使用 GCC 8.2.0。

编辑：

另外，当我使用-std=c11 时，GCC 不是不使用 GNU 扩展吗？这就是本书附录中所写的内容（第 497 页）。

我使用-std=c89 收到警告。

【问题讨论】：

不相关，但.o 扩展名通常用于目标文件，而不是最终可执行文件。
*nix 系统中没有可执行文件的扩展。文件系统不使用它来确定文件的类型。所以通常可执行文件没有扩展名，practice 是正确的。检查您的/usr/bin 目录，您会发现那里的程序也没有扩展名。
关于它的属性说“共享库”可能是因为你的桌面环境。如果我从命令行执行file practice，我会得到practice: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=928002f23b27d5c9bc55a15bf769edfaf3e62c23, not stripped
如果 ELF 可执行文件是 position-independent executable，file 实用程序可以显示 shared object。一些发行版配置 GCC，使其默认创建与位置无关的可执行文件（通常这需要使用 -pie 和 -fPIC 选项）。
@MrLister：虽然传统的 BASIC 实现使用 $ 作为字符串变量名称的后缀，但我不希望尾随的 $ 在 C 中具有类似的含义。如果我正在检查使用这种后缀，我希望程序员正在利用一些特殊的方式来让目标实现处理带有这种后缀的标识符。例如，针对一个平台的编译器可以更快地访问框架指针附近的对象，而不是更远的对象，它可能会将所有名称以$ 结尾的对象放在那些没有的对象之后。

标签： c gcc gcc-warning

【解决方案1】：

您会收到带有-std=c89 -pedantic 的警告。 C99 及更高版本允许在标识符中使用other implementation-defined characters。

【讨论】：

是的。这是参考：gcc.gnu.org/onlinedocs/gcc-8.2.0/cpp/…

【解决方案2】：

据此：GCC Documentation

在 GNU C 中，您通常可以在标识符名称中使用美元符号。这是因为许多传统的 C 实现允许这样的标识符。但是，一些目标不支持标识符中的美元符号机器，通常是因为目标汇编器不允许它们。

所以，$ 是有效的，但它不是一种符合 C 代码的方式。

【讨论】：

它不是有效的 C，仅适用于 GCC C。尝试使用 -ansi 或 -std=C11 进行编译，警告将开始出现。
@Spidey with -std=c11 没有出现警告
@Spidey 不，仍然没有警告。
@Spidey：该标准没有“有效 C”的定义。它对“符合 C 程序”的定义包括至少一个符合 C 实现可接受的任何文本块。在标识符中使用美元符号的源文本不能是“严格符合的程序”，但标准的作者认识到 C 的许多有用性源于编写非可移植程序的能力，这些程序将被某些 C 实现有效处理，甚至如果不是所有人。