Re: Builtins in `std'

[Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>]

Mark Mitchell <mark@codesourcery.com> writes:

| At startup, we push lots of builtins into `std'.  For example, we do:
| 
|   namespace std {
|     extern "C" double fabs (double);
|   };
| 
| This seems like a bad idea to me.

Those are driven by the necessacity of having ::fabs and std::fabs
referring to the same entity (ideally, the one provided by the C
library). 

| ...  For one thing, we accept the
| following entirely bogus program:
| 
|   void f() { std::fabs (3.0); }
| 
| This isn't C, where `void f() { fabs (3.0); }' is a legal program.

Hmm, where is the problem?

| The compiler then has to go through tons of shenanigans if someone
| tries to do something like:
| 
|   namespace std {
|     int fabs;
|   };
| 
| or even:
| 
|   namespace std {
|     double fabs (double); // Should no longer have `C' linkage.
|   };
| 
| Arguably, the former case should not be allowed, but the latter
| probably should be.  (Does V3 give `fabs' C or C++ linkage?  The
| standard says it's unspecified.)

However, we need to ensure that `&::fabs == &std::fabs' evaluates to
true.  On the other hand we have to overload fabs() in std:: only.

| There's no compatibility issue here, becuase we already broke:
| 
|   void f() { fabs (3.0); }
| 
| by putting the builtins in the `std' namespace.

I don't think that is broken.  Because any program which does the
above already says #include <math.h> whose effect is to make fabs
available in both :: and std::.

| ...  Anyone writing a
| standard library should be using `__builtin_fabs' anyhow for tidiness,
| and I know that V3 does this.

We use __builtin_fabs where available.  When it is not, we fall back
to the the C standard library.

| So, any objections to just not doing the insertion into `std'?

Yes. #include <cmath> puts fabs in std:: only.

I have trouble seeing where you're wanting to go.  Could you enlighten
me?

-- Gaby