Name Mangling in C++ - c++

Question

I was going through the article - http://www.geeksforgeeks.org/extern-c-in-c/
There are two example given -
int printf(const char *format,...);
int main()
{
printf("GeeksforGeeks");
return 0;
}
It say this wont compile because the compiler wont be able to find the mangled version of 'printf' function. However, the below give output.
extern "C"
{
int printf(const char *format,...);
}
int main()
{
printf("GeeksforGeeks");
return 0;
}
This is beacuse extern "C" block prevent the name from being mangled. However, the code run and gives output. From where does it get the definition of 'printf'. I read a post which says 'stdio.h' is included by default. If this is true, below code must run. However, it give error that printf is not defined.
int main()
{
printf("GeeksforGeeks");
return 0;
}
Can somebody explain this?

Answer 1

Your compiler is being helpful by treating printf specially as a built-in.
Sample code "tst.cpp":
int printf(char const *format,...);
int foo(int a, char const *b);
int main() {
printf("Hello, World!");
foo(42, static_cast<char const *>("Hello, World!"));
return 0;
}
When compiling with Microsoft's cl compiler command "cl /c tst.cpp" we can inspect the resulting .obj and find:
00000000 r $SG2552
00000010 r $SG2554
00000000 N .debug$S
00000000 i .drectve
00000000 r .rdata
00000000 t .text$mn
U ?foo##YAHHPBD#Z
U ?printf##YAHPBDZZ
00e1520d a #comp.id
80000191 a #feat.00
00000000 T _main
Note that both foo() and printf() are mangled.
But when we compile with /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe via cygwin "g++ -c tst.cpp", we get:
00000000 b .bss
00000000 d .data
00000000 r .rdata
00000000 t .text
U __Z3fooiPKc
U ___main
U __alloca
00000000 T _main
U _printf
Here foo() is mangled and printf() is not, because the cygwin compiler is being helpful. Most would consider this a compiler defect. If the cygwin compiler is invoked with "g++ -fno-builtin -c tst.cpp" then the problem goes away and both symbols are mangled as they should be.
A more up-to-date g++ gets it right, compiling with with /usr/libexec/gcc/i686-redhat-linux/4.8.3/cc1plus via "g++ -c tst.cpp" we get:
00000000 T main
U _Z3fooiPKc
U _Z6printfPKcz
Both foo() and printf() are mangled.
But if we declare printf such that cygwin g++ does not recognize it:
char const * printf(char const *format,...);
int foo(int a, char const *b);
int main() {
printf("Hello, World!");
foo(42, static_cast<char const *>("Hello, World!"));
return 0;
}
Then both foo() and printf() are mangled:
00000000 b .bss
00000000 d .data
00000000 r .rdata
00000000 t .text
U __Z3fooiPKc
U __Z6printfPKcz
U ___main
U __alloca
00000000 T _main

Answer 2

Let's take a look at the relevant standard quotes:
17.6.2.3 Linkage [using.linkage]
2 Whether a name from the C standard library declared with external linkage has extern "C" or extern "C++" linkage is implementation-defined. It is recommended that an implementation use extern "C++" linkage for this purpose.
17.6.4.3 Reserved names [reserved.names]
2 If a program declares or defines a name in a context where it is reserved, other than as explicitly allowed by this Clause, its behavior is undefined.
17.6.4.3.3 External linkage [extern.names]
1 Each name declared as an object with external linkage in a header is reserved to the implementation to designate that library object with external linkage, both in namespace std and in the global namespace.
2 Each global function signature declared with external linkage in a header is reserved to the implementation to designate that function signature with external linkage.
3 Each name from the Standard C library declared with external linkage is reserved to the implementation for use as a name with extern "C" linkage, both in namespace std and in the global namespace.
4 Each function signature from the Standard C library declared with external linkage is reserved to the implementation for use as a function signature with both extern "C" and extern "C++" linkage, or as a name of namespace scope in the global namespace.
What we get from this is that the compiler may assume that printf in any of the given instances always refers to the standard-library-function printf, and thus can have any amount of info about them baked in. And if you get the declaration wrong, or indeed simply provide your own, it is free to do whatever it wants, including but not limited to magically correcting it.
Anyway, you cannot know which language-linkage it expects.