clarification of intent WRT shadowing C library

[Gabriel Dos Reis]

Benjamin Kosnik <bkoz@redhat.com> writes:

| I had a look at the 26_numerics/c_math.cc failure.
| 
| My initial bug report is here:
| http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00517.html
| 
| After discussing this with Jason this morning, he proposed the following code:
| 
| extern "C" {
|   extern double sin(double);
| }
| 
| namespace std {
|   extern "C" double sin(double); // 1
|   using ::sin; // 2
| #if 0
|   inline double 
|   sin(double __x) { return ::sin(__x); } //wrong
| #endif
| }
| 
| int main()
| {
|   std::sin(0);
|   sin(0);
|   return 0;
| }
| 
| Where the first option (designated by // 1) is the preferred solution,
| as this explicitly makes the std::sin refer to the extern "C"
| function.

Well, I see Jason's point but I'm not comfortble with it.  We should
proceed in a way so that <cxxx> hearders don't dump C function names
in the global scope.  That is why I'm favouring the _C_legacy namespace
solution.  Yes, it is frustrating the library is not yet functionning
out of box.  Let's try hard.

[...]

| Jason, will this work for structs as well as functions (ie time.h's
| struct tm?) (the answer is no, and the current c_std approach will work.)
| 
| thus
|   inline double 
|   acos(double __x) { return ::acos(__x); }
| 
| should be
|   extern "C" double acos(double __x);


What is wrong with 

  inline double
  acos(double __x) { return _C_legacy::acos(__x); }


?

| and
| #if _GLIBCPP_HAVE_TANF
|   inline float 
|   tan(float __x) { return ::tanf(__x); }
| #else
|   inline float 
|   tan(float __x) { return ::tan(static_cast<double>(__x)); }
| #endif
| 
| should remain intact as they refer to different names.

Yep.

-- Gaby