Re: Protected visibility for glib



On 03/14/2010 10:52 PM, Ryan Lortie wrote:
>   - replace G_BEGIN_DECLS/G_END_DECLS with "protected" visibility
>     pragmas.  This means that any symbol declared in a header file
>     will end up with protected visibility.

which means what exactly? The gcc docs only say that "`protected' and
`internal' are pretty useless in real-world usage".

>   - deal with the take-address-of-protected-symbol problem with a pair
>     of macros.  G_INTERNAL_FUNC() must be used anywhere when taking the
>     address of a glib function from inside of glib (ie: when creating a
>     hash table with g_str_hash(), for example).

It looks to me like "must be used" here means "if you don't use it, it
will still compile, and 'make check' will still pass, and then it will
silently fall back to doing a PLT lookup at runtime", right? People
*will* forget to use it in new code. It would be nice if you could turn
that into a compile/link-time error. (Maybe by renaming or hiding the
symbol in the header file when compiling glib?)

Actually, if you renamed the symbol in the header file when compiling
glib, would you even need G_INTERNAL_FUNC? Just have some macro
before/after/around the declaration of g_str_hash that is a no-op when
#including the installed header, but during glib compilation would
"#define g_str_hash IA_g_str_hash" and change its visibility.

Which I guess is sort of equivalent to: if there are only 8 functions
that need renaming in the new system, then couldn't we just maintain
galias.h by hand?

> I've only made changes to the glib/ directory -- not
> gobject/ or gio/ (although those could easily use the same technique).

gobject and gio also have this problem where their pltcheck stuff needs
to include a complete list of all of the libglib-2.0.so functions that
they call, for some reason. Does that go away?

>   - Makes it easier for people not to update the symbols file properly. 

Not really. If you don't run "make check" there's nothing to remind you
to update the symbols file now either.

-- Dan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]