This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

clarification of intent WRT shadowing C library



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.

This is considerably different than current practice in the current
shadow (include/c_std/*) and non-shadowed (include/c/*) namespace
solutions.

Before I go about making massive changes to include/c/bits/std_c*.h,
I'd just like to make sure that my understanding of the above
situation is correct. 

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);

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.


anyway.

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]