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 _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
