[c++] builtin functions and namespaces

[c++] builtin functions and namespaces

[brent verner]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

Hi,

  The code below, representative of what is necessary for std compliant
c headers, does not compile w/o the '-fno-builtin' being passed to g++.
This is due to abs being a builtin function in the compiler. The 
_initially obvoius_ solution is to have g++ default to -fno-builtin
whenever --enable-cshadow-headers is requested.  What side-effects to
a default of -fno-builtin am I _not seeing_? Shouldn't the compiler be
able to recognize _in which namespace_ its builtin function is being
requested/declared?

Compiling this causes the complaint that abs(int) is ambiguous:
  abs(int)
     &&
  std::abs(int)
however, commenting out the 'using namespace std;' line, the complaint
is that abs(int) is _undeclared_.  Now, forgive me for not understanding
enough of this, but, for the original ambiguity to exist, didn't 
abs(int) have to be declared? How did removing the using directive, also
take away the delcaration of abs(int)? Why is the builtin being declared
in the global namespace _only_ when it is visible via another exposed 
namespace? (forgive me if my terminology is wrong).

namespace _C_ {
  extern "C" {
    extern int puts(const char*);
    extern int abs(int a);
  }
}
namespace std {
  using ::_C_::puts;
  using ::_C_::abs;
}

using namespace std;

int
main()
{
  puts("yup");
  abs(1);
}


thanks,
  Brent

-- 
Damon Brent Verner                        o      _     _         _
Cracker Jack® Surprise Certified  _o     /\_   _ \\o  (_)\__/o  (_)
brent@rcfile.org                _< \_   _>(_) (_)/<_    \_| \   _|/' \/
brent@linux1.org               (_)>(_) (_)        (_)   (_)    (_)'  _\o_

Re: [c++] builtin functions and namespaces

[brent]

On 27 Sep 2000 at 16:39 (+0200), Martin von Loewis wrote:
| > gcc/cp/call.c: build_new_function_call()
| >   which kicks the error because
| > gcc/cp/call.c: tourney()
| >   returns 0 because
| > gcc/cp/call.c: joust()
| >   returns 0 because joust can't decide whether to pick the 
| >   ::std::__builtin_fn or ::__buitlin_fn as the better candidate

ok, so far I see:
  init_decl_processing()
  c_common_nodes_and_builtins()
    [the builtins in question are created here]
  ...
  yyparse()
  finish_call_expr()
  build_x_function_call()
  build_new_function_call()
    [error emitted in here]

I tried to follow the (desired) function's declaration, but seem to
be stuck in bison.simple (or possibly just tired and impatient :)

...anyway, my thought it to stuff all of the builtins into an anon
namespace at creation time, so they don't appear in ::. this means
that foreach fn declaration, we'd have to traverse a list of builtins
to see if our declared fn name matches a builtin, pull the builtin
into the current_namespace.

is this a reasonable approach? I'm not quite sure (yet) where this'd
be done, but I'll dig for that tomorrow.

another option (still) _appears_ to be to check if the function decl
is _also_ a builtin decl at call time.

thoughts? advice?

question: (excuse my lack of knowledge, please)
  given an existing function decl tree, how would I (re)classify
  that tree node as having been defined in a namespace, when it
  was originally _not_?


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.