Set the time machine to 1988. The C language has not yet been standardized. Everybody had their own libraries for doing stuff, and some of them even pretended to be compatible with each other. The Microsoft C compiler, for example, came with a bunch of functions like unlink
and stat
to provide sort-of compatibility with Unix-sort-of source code.
And then the C standard was ratified in 1989. Now things got interesting, because those functions were not part of the C standard. Standard-conforming C programs were welcome to define functions with those names, and the rules say that this is perfectly legal and are not references to the identically-named Unix-like functions.
Now, there was a lot of code written for the Microsoft C toolchain that used these sort-of-Unix-ish functions, and renaming those functions would cause those programs to break.
So should we rename the Unix-ish functions in the Microsoft C library, in order to conform to the C standard? Or should we leave the functions in the Microsoft C library under their pre-standard names, to keep existing code working?
The Microsoft C library renamed these Unix-ish function to have a leading underscore. So unlink
became _unlink
, and so on. A program that didn’t use the Unix-ish library functions could define its own function called unlink
, and everything would work just fine. But if the program actually wanted to use the unlink
function from the Unix-ish library, this magic library OLDNAMES.LIB
would step in.
The OLDNAMES.LIB
library doesn’t contain any code of its own. Rather, it contains name redirections that say, “Hey, I have a symbol called unlink
, in case you were looking for it. Wait, you want to know what this symbol represents? Um, it represents a symbol named _unlink
. Good luck with that.”
If the linker cannot find a symbol named unlink
, it turns to OLDNAMES.LIB
as a library of last resort, and that library resolves the symbol unlink
, but replaces it with an unresolved symbol named _unlink
. The linker then goes through the symbol resolution process again, and this time it finds _unlink
in the regular C library.
The net result is that your attempt to call the function unlink
got redirected to the function _unlink
, but only if you didn’t already have a function named unlink
.
You can
suppress the OLDNAMES.LIB
library
in various ways, most notably by passing the /NODEFAULTLIB
flag, which can be abbreviated to the somewhat enigmatic /NOD
.
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
深入理解并行编程
[美] Paul E.Mckenney(保罗·E·麦肯尼) / 谢宝友 鲁阳 / 电子工业出版社 / 2017-7-1 / 129
《深入理解并行编程》首先以霍金提出的两个理论物理限制为引子,解释了多核并行计算兴起的原因,并从硬件的角度阐述并行编程的难题。接着,《深入理解并行编程》以常见的计数器为例,探讨其不同的实现方法及适用场景。在这些实现方法中,除了介绍常见的锁以外,《深入理解并行编程》还重点介绍了RCU的使用及其原理,以及实现RCU的基础:内存屏障。最后,《深入理解并行编程》还介绍了并行软件的验证,以及并行实时计算等内容......一起来看看 《深入理解并行编程》 这本书的介绍吧!
html转js在线工具
html转js在线工具
RGB CMYK 转换工具
RGB CMYK 互转工具