Re: [C++ PATCH] Fix extern "C" function and namespace handling

[brent verner <brent at rcfile dot org>]

On 10 Oct 2000 at 21:23 (-0700), Kriang Lerdsuwanakij wrote:
| 
| On Sun, 8 Oct 2000, brent verner wrote:
| 
| > namespace _C_ {
| >   extern "C" int abs(int a);
| > }
| > namespace std {
| >   inline int abs(int a){ return a >= 0 ? a : - a; }   // error
| 
| I believe we need extern "C" in the above declaration.  The standard
| mentions in 7.5 para 6 that
| 
|   ... Two declarations for an object with C language linkage with the
|   same name (ignoring the namespace names that qualify it) that
|   appear in different namespace scopes refer to the same object. ...
| 
| Without extern "C" in the second declaration, I think this is a
| separate function.  

agreed. it _must_ be recognized as a separate function, declared in
the std:: namespace. The code posted is code that must be compiled
for libstdc++-v3 to work w/o -fno-builtins as default for the g++
frontend -- it is infact, a trimmed down case which caused the
libstdc++-v3 build to fail w/o '-fno-builtin'.

The problem is when 'using std::abs;' is handled by do_member_using_decl,
the tree _also_ sees the builtin abs at global scope, and bails. a suggestion
to stuff builtins into std:: has been made, but I _don't think_ that will
solve the real problem, since the re-definition of abs(int) will raise the
error (I believe).

Your most recent patch resolves _many_ issues related to the builtin
functions in the c++ frontend, but I think the handling of builtins
needs to be re-implemented (wishing I had more than a couple hours a 
day for this endeavour :( ). after a _number_ of _bad_ ideas of how 
builtins could be handled, it just hit me that there _may_ be no reason
to have the conflicting builtins in the tree(s) at all, rather to do
the following...

build_function("__builtin_FUNC",,,,) in c_common_nodes_and_builtins
fully parse file
then at call time:
  solicit_builtin(decl){
    /* look up a matching builtin function for decl */
  }

this would allow us to parse the document w/o any fear of builtins
colliding in _any_ namespaces, while allowing the benefits of the 
builtins to be realized.

Is there any reason the builtins _need_ to be visible prior to 
call time?

thanks.
  brent

-- 
All opinions expressed are My own, unless otherwise attributed. In
presenting facts, I expressly reserve the right to be Wrong. Portions
of this message authored by Me are subject to the Free Thought License.