Question

I find such examples in Boost code.

namespace boost {
   namespace {
     extern "C" void *thread_proxy(void *f)
     {
       ....
     }

   } // anonymous
   void thread::thread_start(...)
   {
       ...
       pthread_create(something,0,&thread_proxy,something_else);
       ...
   }
} // boost

Why do you actually need this extern "C"?

It is clear that the thread_proxy function is private internal and I do not expect that it
would be mangled as “thread_proxy” because I actually do not need it mangled at all.

In fact, in all my code that I had written and that runs on many platforms, I never used extern "C" and this had worked as-is with normal functions.

Why is extern "C" added?

---

My problem is that extern "C" functions pollute the global namespace and they are not actually hidden as the author expects.

This is not a duplicate!
I’m not talking about mangling and external linkage. It is obvious in this code that external linkage is unwanted!

Answer: The calling conventions of C and C++ functions are not necessarily the same, so you need to create one with the C calling convention. See 7.5 (p4) of C++ standard.

Answer 1

It is clear that the thread_proxy function is private internal and I do not expect that it would be mangled as “thread_proxy” because I actually do not need it mangled at all.

Regardless, it’s still going to be mangled. (Had it not been extern "C") That’s just how the compiler works. I agree it’s conceivable a compiler could say “this doesn’t necessarily need to be mangled”, but the standard says nothing on it. That said, mangling doesn’t come into play here, as we aren’t trying to link to the function.

In fact, in all my code that I had written and that runs on many platforms, I never used extern "C" and this had worked as-is with normal functions.

Writing on different platforms has nothing to do with extern "C". I expect all standard C++ code to work on all platforms that have a standard C++ compliant compiler.

extern "C" has to do with interfacing with C, which pthread is a library of. Not only does it not mangle the name, it makes sure it’s callable with the C calling convention. It’s the calling convention that needs to be guaranteed, and because we can’t assume we are running on a certain compiler, platform, or architecture, the best way to try and do that is with the functionality given to us: extern "C".

My problem is that extern "C" functions pollute the global namespace and they are not actually hidden as the author expects.

There’s nothing polluting about the above code. It’s in an unnamed namespace, and not accessible outside the translation unit.