Re: Is overriding a function of a library in accordance with C++ standard?
Earl Purple wrote:
Lighter wrote:
Is overriding a function of a library in accordance with C++
standard?
The following code is passed by the VS 2005 and Dev C++.
#include <cstdlib>
#include <iostream>
using namespace std;
size_t strlen(const char* p)
{
return 0;
} // !!! Note this !!! The standard library function strlen is
deliberately overriden.
No, you have defined strlen in the global namespace. The standard one
is in the std namespace, and then it is in <cstring> I think not
<cstdlib>.
Sorry, did he said he was overriding std::strlen or libc strlen?
I thought you might get a link error if it clashes with a
symbol in the C runtime library, should that be linked in, but you
obviously don't here. Wouldn't say you can guarantee that though.
Is the following behavior of gnu ld is not in line with C++ Standard?
info ld
-lARCHIVE
--library=ARCHIVE
....
The linker will search an archive only once, at the location where
it is specified on the command line. If the archive defines a
symbol which was undefined in some object which appeared before
the archive on the command line, the linker will include the
appropriate file(s) from the archive. However, an undefined
symbol in an object appearing later on the command line will not
cause the linker to search the archive again.
....
-Bsymbolic
When creating a shared library, bind references to global symbols
to the definition within the shared library, if any. Normally, it
is possible for a program linked against a shared library to
override the definition within the shared library...
In other words, normally, any reference to a symbol is resolved to the
first found definition of that symbol. Which may is a basis of existing
*nix practice of overriding library functions by those found in .o.
int main(int argc, char *argv[])
{
system("PAUSE");
return EXIT_SUCCESS;
}
You haven't called strlen so the linker stripped it out. Thus you
wouldn't get a link error. Try using it and see what happens.
Does not look like the linker stripped something. There was probably no
references in the program to strlen, so the linker did not consider
strlen symbol.
[]
2) At link time, the compiler first searches the object files for
all
the unresolved symbols; if it fails to find some symbols, then the
compiler will search the libraries which are included in the project
to
find the symbols.
And if it finds them twice it will fail to link.
Quite true, with a caveat that only if more than one definition of that
symbol come from .o. If it applied to libraries as well, one would not
be able to mention a library in the linker command line more then once.
The linker will look at main and any globals and work down the tree to
see what it needs to link in. That's why it's called linking. Anything
left on the shelf is ignored, like your strlen function.
3) If the object files containes a symbol, then the symbols that
have
the same name in the libraries will be ignored.
No they won't be, they will cause a clash, but only if the exact name
matches.
It seems to me *nix linkers do not work this way, do they? What about
windoze ones?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]