Re: typedef-named class member functions can be public

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  5, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

>   typedef struct {
>     void f();
>   } S;

>   S s;

>   s.f();

> Is that supposed to be an external call or an internal call?

Hmm...  External, right.  BTW, thanks for the testcase :-)  I'll
derive the testcase I'm going to post along with whatever patch I come
up with from that, if you don't mind.

>> BTW, I've just noticed that static data members are always marked as
>> TREE_PUBLIC, regardless of the linkage of the enclosing class type.

>> [cp/decl.c] grokvardecl():
>> [...]
>> /* In class context, static means one per class,
>> public access, and static storage.  */
>> if (DECL_CLASS_SCOPE_P (decl))
>> {
>> TREE_PUBLIC (decl) = 1;
>> TREE_STATIC (decl) = 1;
>> DECL_EXTERNAL (decl) = 0;
>> }

>> Is this not wrong in case the class has no or internal linkage?

> Yes, that is wrong, if there is no other code that corrects it.

Ok, I'll dig deeper.  The unfortunate thing is that this chunk of code
seems to have been heavily rewritten since the branch I'm working on
was taken, which means I may have to do it twice.  Oh, well, that's
just part of the fun :-)

>> Problem is, when we get to the point of knowing whether the enclosing
>> class has linkage, we've already created the decls of all its members.

> Right; I think you have to go back and fix them up.  Or, even better,
> notice that you're in a typedef of the right flavor *first*, and pass
> that information into the class.

Unless I misunderstand what you mean, there's no way to do this.
Consider:

typedef struct { /* ... */ } *foo, **baz, bar;

How would you know about the class name when finishing up the class
type?  Or does it get done only at the end of the complete decl?

>> Would it be reasonable to just set the TREE_PUBLIC bit in all function
>> or static-data class members?  Or would this somehow break for member
>> functions?

> You can't get out of this in an easy way.  TREE_PUBLIC must be correct
> or things will go wrong.

I believe you, but I don't see what can go wrong.  Care to give me an
example, or at least a pointer?  Thanks,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer