Re: C++: Anticipated declaration of builtins.

[Gabriel Dos Reis <gdr@integrable-solutions.net>]

Roger Sayle <roger@eyesopen.com> writes:

| > | > 1) Shouldn't we pre-declare the function at global scope, then
| > | >    do a using-declaration at the standard scope?
| > |
| > | The problem here is that they need to be treated as two independent
| > | pre-declarations.  If a prototype or declaration is given for
| > | one, it does not automatically anticipate/declare the other.  Hence,
| > | we require separate DECLs with independent DECL_ANTICIPATED flags.
| >
| > Hmm, why do we need to have two independent declarations for the same
| > builtin?
| 
| Because of the way that duplicate_decls overwrites the original
| decl when redeclaring a declaration, such as when an anticipated
| built-in function is prototyped.
| 
| If a single decl was shared between ::strlen and std::strlen, then
| the destructive modification of the first decl would side-effect
| the second.  I'd hoped this was clear from my reference to the
| DECL_ANTICIPATED flag.  Setting it to true for the decl in the
| first namespace should not automatically set the DECL_ANTICIPATED
| field of the pre-declaration in the second namespace.

I understood your original statement with the reference to
DECL_ANTICIPATED flag.  What I still do not understand is why one
would want to keep ::strlen separate from std::strlen for example.
The point I'm trying to understand is why we should not have both
behave as if

    <antitpated declaration for strlen>
     namesapce std
     {
       using ::strlen;
     }

(note that, that is, for example, the way "C" functions are malassed by
the C++ library if #include <xxx.h> -- although we would have preferred
the other way around)

My question is why do we want to mess up with duplicate declares in
situation like this

   using namespace std;

    // use strlen;

if we keep two separate declarations then we run into ambiguous use,
which should not be the case.

| I believe/hope that the DECLs themselves take up very little space,
| they don't contain any RTL, they share their types and other major
| fields.  So the DECL itself just acts a place holder, associating
| the namespace/identifier, with its types, flags and attributes.

At this point, I'm more concerned with name lookup than with RTL stuff.

| > If we have the same builtin declared twice with possibly two
| > incompatible declarations, it occurs to me that we're calling for
| > trouble.  Is there any case where that could be useful?
| 
| The DECL_BUILT_IN and similar attributes are only preserved if
| the declarations are compatible.  If the type of the redeclaration
| doesn't match the anticipated/pre-declared type, the old decl is
| just completely overwritten.
| 
| Consider:
| 
| // Global namespace declaration matches anticipated type.
| extern "C" size_t strlen(const char *);
| 
| // std namespace declaration doesn't match anticipated type.
| namespace std {
| double strlen;
| }

This is precisely a situation we should not tolerate.  ::strlen and
std::strlen should be synomous.  Is there any real example from the
standard library (GNU-extended) where the above scenario could happen
or would be useful?

| We end up modifying or overwritting the anticipated decls for each
| redeclaration, but clearly with very different information in each.

That cannot happen if we have a using-declaration.  No?

| Its not that we use the same "built-in" function with different
| types, but that we may or may not completely overwrite the decls
| based upon different types, i.e. redeclare the DECL associated with
| the identifier differently in different contexts.  The built-in only
| gets used when the types match.

A using-declataion just brings a name into scope with no additional
type or attributes information.  Therefore, I cannot see no oppotunity
for not completely overwriting a decl. With a using declaration, there
is a master source declaration, the used-name just propogates whatever
the master carries.  

| A less ambiguous/confusing example might be:
| 
| int strlen;
| namespace std { double strlen; }
| 
| in which neither declaration matches the pre-declared built-in.

Do we have any concrete example like that in the standard library? 
I'm under the impression that, that is not addressing any real issue
with the standard library functions.  It may be possible that I may be
missing something, then that is a reason why I need to understand why
you did the thing you did.  Right Now, I can see only disavantages.

Actually I would see the following scheme for pre-declaring standard
library functions as builtins:

   namespace std
   {
      foo builtin(bar);
   } 

   using std::builting;

| > The point is that I have been reworking some part of th name lookup
| > machinery, and that particular behaviour crashes the compiler until I
| > realized that declarations (of builtins) in the outer space is no good.
| > If they  are supposed to be pre-declared at the global scope (as the
| > comment indicates), then their DECL_CONTEXT should point to
| > global_namespace.  I'll make that change, once I understand the other
| > issue.
| 
| That sounds very reasonable.  Fortunately, fixing this should be
| independent of the first issue.  

Thank you, I'll make that separate change.

I'll still unclear about the first issue though.

-- Gaby