On Jan 14, 2008 10:57 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
But that was just one example of a name conflict. There could be other name conflicts if more than one plugin was loaded without G_MODULE_BIND_LOCAL.
Of course, any module that needs this ability should make some effort to avoid using symbol names that are likely to clash with other plugins.
The main problem is with the plugin interface symbols: cleanup configure geany_callbacks geany_data info init version_check
But I think there is a fairly simple way to avoid this, instead of checking for the existence a symbol like:
make_me_global = TRUE;
We could check for something like this:
symbol_suffix = "_geanylua";
Now, we open the file *with* the G_MODULE_BIND_LOCAL flag, and if we find the symbol_suffix variable, we also check to make sure the normal interface symbol names ( init, info, cleanup, etc ) must *not* exist in this plugin. If it passes all these tests, we store the value of the symbol_suffix variable, close the plugin, and we should now be able to safely re-open it in the global namespace. Only this time, when we initialize the plugin, we append this symbol_suffix string to search for its internal symbol names, e.g. init_geanylua, info_geanylua, cleanup_geanylua, etc.
Apart from naming conflicts, G_MODULE_BIND_LOCAL also prevents loading a plugin that tries to access an unresolved symbol.
But since we first open the plugin with this flag, if that fails, we certainly wouldn't try to re-open it without the flag.
Untested code would cause Geany to segfault.
I'll bet I can think of at least a thousand other ways for an untested plugin to crash Geany. :-)
I don't have much experience with dynamic modules.
That makes two of us.
Is there really no other way that the Lua plugin can load those modules for itself only?
If anyone knows the answer to this, I would love to hear it, but I have already tried everything I could think of, and nothing else worked.
- Jeff