Re: [RFC] Module API Introspection

On Fri, Jan 24, 2014 at 3:15 PM, Johannes Schlüter <johannes@schlueters.de> wrote: > On Fri, 2014-01-24 at 15:01 +0100, Julien Pauli wrote: >> > * I think (didn't check) there will be issues due to tsrm >> symols >> > when an extension provides INI options and TSRM/non-TSRM >> doesn't >> > match >> >> I don't get it. We access very few fields of zend_module_entry, and >> they are all placed before the _zend_ini_entry one. So if there is a >> problem of alignment mismatch, we won't be affected AFAIK. >> > INI settings are in a global variable, referring to specific update > handlers. I remember cases where the error while loading extensions was > about missing OnUpdateBool. I can imagine other similar errors. > >> > * Afaik Windows' LoadLibrary doesn't do lazy loading but will >> > confront the user with a dialog box when symbols can't be >> found >> > * ... I'm sure there are more >> >> Same : the same happens on WIndows when you try to load an extension. >> So , we already manage this behavior and cant do anything about it. >> > The point is: What is the benefit of such a feature if it often can't be > used? Maybe we can think more and find a better way to approach this? I'm all open to new ideas :-) > I don't have a better idea than something like a shell script doing > strings xdebug.so | grep API -- which obviously is no good idea > either, but maybe somebody is smarter than me. That's what we ended telling to attendees : we have no way in PHP actually to check the API of an extension, except by trying to load it. However, GNU tools playing with ELF format are a global Unix solution working, but not coming from PHP obviously. The only safe thing we could do, is wrapping libelf and play with it. Somehow dirty and adds a new dependency :-p Julien