为什么 clang++ 的行为与 clang 不同，因为前者是后者的符号链接？答案

【问题标题】：why clang++ behaves differently from clang since the former is a symbol link of the latter?为什么 clang++ 的行为与 clang 不同，因为前者是后者的符号链接？
【发布时间】：2012-05-08 17:34:50
【问题描述】：

我有一个尝试修改 const 字符串文字的 C 程序。现在我了解到这是不允许的。

当我使用clang test.c 编译代码时，编译器不会发出警告。但是当我用clang++ test.c 编译它时，它会给出一个警告：

test.c:6:15: 警告：从字符串文字转换为 'char *' 已弃用 [-Wdeprecated-writable-strings] char *s = "你好世界"; ^

问题是clang++ 只是clang 的符号链接：

ll `which clang++`
lrwxr-xr-x  1 root  admin  5 Jan  1 12:34 /usr/bin/clang++@ -> clang

所以我的问题是clang++ 的行为与clang 的行为有何不同，因为它是clang 的符号链接？

【问题讨论】：

标签： linux macos clang symlink clang++

【解决方案1】：

Clang 正在查看它的 argv[0] 并根据它看到的内容改变它的行为。这是一个不常见且令人沮丧但并不罕见的技巧，至少可以追溯到 4.2BSD ex 和 vi，它们是相同的可执行文件，而且可能更远。

在这种情况下，clang 将您的 .c 文件编译为 C，clang++ 将其编译为 C++。这是一个你不应该依赖的历史缺陷；使用适当的编译器命令和确保您的文件扩展名反映文件的真实内容。

【讨论】：

您的意思是 bash 正在查看 argv[0] 并改变行为吗？所以在 bash 中硬编码 clang++ 的行为与 clang 不同？
对不起，我想的不够。它在clang 中硬编码。谢谢：）
我能否引用这种技术“不常见且不受欢迎”？无意抨击，只是好奇。
我不知道“不常见”部分的引用，但here's one fairly influential place where it's discouraged 的理由是您永远不知道最终用户何时可能想要重命名程序而不改变其行为，例如因为你有两个不同的编译器，它们不能都是/usr/bin/cc。

【解决方案2】：

按照惯例，调用命令的名称被传递为argv[0]；程序基于此改变其行为并不罕见。（历史上，ln、cp 和 mv 是 Research Unix 上同一个可执行文件的硬链接，并使用 argv[0] 来决定要执行的操作。此外，大多数 shell 在 @987654327 中寻找前导 - @ 来决定它们是否应该是一个登录 shell。）通常还有其他一些方法可以获得相同的效果（选项、环境变量等）；一般情况下，您应该使用它而不是玩argv[0] 游戏。

这样做是有原因的，但在大多数情况下，依赖它或围绕它设计程序并不是一个好主意。

【讨论】：