Re: [Vala] Private variable/function/class

[Evan Nemerson <evan coeus-group com>]

On Mon, 2013-07-15 at 15:41 +0200, Ulink wrote:
> Hi,
>
> If I'm declaring a private variable/funtion/class and compile it to a
> "package" (.so), it is not shown up in the .h and .vapi, this is ok.
>
> However, all this symbols ARE exported in the .so symbol table!
>
> If one bind more than one .so with e.g. the same PRIVATE variable named
> "testVar" it acts like a one single global variable/function, but it
> should be private!

In practice this really isn't an issue.  Beyond the fact that I don't
think non-instance variables are widely used (I certainly don't use
many), they should be within your namespace anyways.

Also, -fno-common may solve this--I haven't played with it enough to be
sure.  I'm also not sure how compilers other than GCC behave here.

> I think valac should compile private variables/functions using the C
> "static" modifier?

static restricts the symbol to a single C compilation unit.  Private
non-instance members are accessible from anywhere within the Vala
compilation unit, and a single Vala compilation unit can (and more often
than not does) result in multiple C compilation units.

Private instance members (such as methods in classes without the
"static" Vala keyword) which are only accessible from within an instance
are, last time I checked, marked as static in the generated C.  So are
generated symbols such as delegate and free function wrappers.

In other words, AFAIK everything which *can* be marked as static without
breaking compilation of the generated C already is.

It may be possible to hack something together using attributes/pragmas,
and the C preprocessor (for example, see
http://gcc.gnu.org/wiki/Visibility), but it would have to rely on
non-standard compiler characteristics and wouldn't work everywhere.


-Evan