I'm working with a library (linked shared, using dll/so) written in C which sets the errno variable if errors occurs. This library has got a function which prints the error information and the errno number on terminal/command line. My program that uses this library is written in C++.
I've made the following observation in Windows (Visual Studio 2010): If there was an error for example and then I set the errno to 0 after it, the printing function gets the old errno and prints that. I set it directly: errno = 0;.
As I'm developing under Linux and Windows I tested it on both: In Linux it works as expected means the printing function will print 0 for the errno value where as in Windows the old errno is used.
Further it is just a single thread application.
So my question is:
Are there two global errno variables one for my library (dll) and one for my application in Windows? If so is it because my program is written in C++ and the library in C using a different runtime?
I already read the documentation of MSDN about errno but can't find any informations that helps. In the Linux manpage about errno is written:
errno is thread-local; setting it in one thread does not affect its value in any other thread.
But as I said I have just one thread and in Linux it works.
Edit #1: I've read this answer on SO which states:
Where it gets complicated is when you have
externglobal variables. Here, Windows and Unix-like systems are completely differentIn the case of Windows (.exe and .dll), the
externglobal variables are not part of the exported symbols. In other words, different modules are in no way aware of global variables defined in other modules. This means that you will get linker errors if you try, for example, to create an executable that is supposed to use anexternvariable defined in a DLL, because this is not allowed. You would need to provide an object file (or static library) with a definition of thatexternvariable and link it statically with both the executable and the DLL, resulting in two distinct global variables (one belonging to the executable and one belonging to the DLL).
But there isn't anything statically linked?
