为什么C编译器会预先指示外部名称？
我已经在C中工作了很长时间，以至于编译器通常会在extern的开始时添加下划线，但是才理解...但是，今天的另一个问题让我想知道添加下划线的真正原因。 a wikipedia文章声称一个原因是：
C编译器的常见做法是将所有外部范围计划标识符的领先下划线预先分配，以避免冲突和运行时语言支持的贡献
我认为对此至少有真实性的内核，但似乎并没有真正回答这个问题，由于如果将下划线添加到所有外部，则无济于事，防止冲突。
有人对领先的下划线有很好的信息吗？
UNIX creat（）系统调用的原因是添加的部分原因是以“ e”结尾？我听说某些平台上的早期链接器的名称限制为6个字符。如果是这样，那么准备向外部名称的下划线似乎是一个彻头彻尾的疯狂主意（现在我只有5个字符可以玩...）。
I've been working in C for so long that the fact that compilers typically add an underscore to the start of an extern is just understood... However, another SO question today got me wondering about the real reason why the underscore is added. A wikipedia article claims that a reason is:
It was common practice for C compilers to prepend a leading underscore to all external scope program identifiers to avert clashes with contributions from runtime language support
I think there's at least a kernel of truth to this, but also it seems to no really answer the question, since if the underscore is added to all externs it won't help much with preventing clashes.
Does anyone have good information on the rationale for the leading underscore?
Is the added underscore part of the reason that the Unix creat() system call doesn't end with an 'e'? I've heard that early linkers on some platforms had a limit of 6 characters for names. If that's the case, then prepending an underscore to external names would seem to be a downright crazy idea (now I only have 5 characters to play with...).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果编译器提供了运行时支持，则预先向所有外部范围计划标识符提出了所有外部范围计划标识符，以避免运行时语言支持的贡献，您会认为，您认为预先确定一个下端以进行更有意义运行时支持中的少数外部标识符！
当C编译器首次出现时，这些平台上C编程的基本替代方法是用汇编语言编程，并且（偶尔仍然）将链接在汇编和C中的对象文件链接在一起。在外部C标识符中添加的下划线是避免与您自己的汇编代码中的标识符发生冲突。
（另请参见 gcc的
asmIf the runtime support is provided by the compiler, you would think it would make more sense to prepend an underscore to the few external identifiers in the runtime support instead!
When C compilers first appeared, the basic alternative to programming in C on those platforms was programming in assembly language, and it was (and occasionally still is) useful to link together object files written in assembler and C. So really (IMHO) the leading underscore added to external C identifiers was to avoid clashes with the identifiers in your own assembly code.
(See also GCC's
asmlabel extension; and note that this prepended underscore can be considered a simple form of name mangling. More complicated languages like C++ use more complicated name mangling, but this is where it started.)如果C编译器始终在每个符号之前预先提出一个下划线，则
然后，启动/c-runtime代码（通常用汇编编写）可以安全地使用不以下划线开头的标签和符号（例如符号“ start”）。
即使您在C代码中编写start（）函数，它也会在对象/ASM输出中以_ start生成。 （请注意，在这种情况下，C代码不可能生成一个不会以下划线开头的符号），因此启动编码器不必担心为每个符号发明晦涩难以置信的符号（例如$ _DONTUSE42％$））他/她的全球变量/标签。
因此，链接器不会抱怨名称冲突，而且程序员很高兴。 :)
以下内容与编译器的实践不同，以其输出格式进行下划线。
对于C系统库和其他系统组件，这是一个约定。 （以及诸如__file__等的事物）。
（请注意，这样的符号（ex：_time）可能会导致2个领先的下划线（__Time）在生成的输出中）
if the c compiler always prepended an underscore before every symbol,
then the startup/c-runtime code, (which is usually written in assembly) can safely use labels and symbols that do not start with an underscore, (such as the symbol 'start').
even if you write a start() function in the c code, it gets generated as _start in the object/asm output. (note that in this case, there is no possibility for the c code to generate a symbol that does not start with an underscore) so the startup coder doesnt have to worry about inventing obscure improbable symbols (like $_dontuse42%$) for each of his/her global variables/labels.
so the linker wont complain about a name clash, and the programmer is happy. :)
the following is different from the practise of the compiler prepending an underscore in its output formats.
that is a convention followed, for the c sytem libraries and other system components. (and for things such as __FILE__ etc).
(note that such a symbol (ex: _time) may result in 2 leading underscores (__time) in the generated output)
据我所知，避免命名冲突。不是针对其他外部变量，而是更多，因此当您使用库时，它将不会与用户代码变量名称冲突。
From what I always hear it is to avoid naming conflicts. Not for other extern variables but more so that when you use a library it will hopefully not conflict with the user code variable names.
主要功能不是可执行文件的实际入口点。一些静态链接的文件具有最终调用MAIN的真实输入点，而这些静态链接的文件拥有并非以下划线开头的名称空间。在我的系统中，在 /usr /lib中，有gcrt1.o，crt1.o和dylib1.o等。每个都有一个“启动”功能，而无需下划线，最终将称为“ _main”入口点。除这些文件外，其他所有内容都具有外部范围。历史记录与在一个项目中混合组装程序和C的混合有关，在该项目中，所有C都被认为是外部的。
The main function is not the real entry point of an executable. Some statically linked files have the real entry point that eventually calls main, and those statically linked files own the namespace that does not start with an underscore. On my system, in /usr/lib, there are gcrt1.o, crt1.o and dylib1.o among others. Each of those has a "start" function without an underscore that will eventually call the "_main" entry point. Everything else besides those files has external scope. The history has to do with mixing assembler and C in a project, where all C was considered external.
来自 wikipedia ：
From Wikipedia: