Re: php_module_startup: more than one additional_module impossible?

saguyer@gte.net wrote: [...]

A solution might be to add a new php_module_startup_ex(...) function with the right parametes, and let php_module_startup() be a wrapper around it. At least this would keep existing SAPI-modules working: /* {{{ php_module_startup */ int php_module_startup(sapi_module_struct *sf, zend_module_entry *additional_modules, uint num_additional_modules) {

    return php_module_startup_ex(
        sf, &additional_modules, num_additional_modules );

} /* {{{ php_module_startup_ex */ int php_module_startup_ex(sapi_module_struct *sf, zend_module_entry **additional_modules, uint num_additional_modules) { /* old php_module_startup() body here */ } What do you think?

My opinion...your solution clearly achieves your desired goal. However, I don't like the idea of leaving php_module_startup with a broken interface. Since only one module would work, the num_additional_modules param is misleading. I'd rather fix the bug and have folks patch their code to the new face

You are right. Having a clear interface is probably more important than short-term reduction of work for a few developers.

(there ain't that many callers, and it's a trivial fix). Course, I have no authority in the matter ;-)

Additionally, it is strange to me that we can't call php_startup_extensions() at app init time after having called php_module_startup(). But I don't understand the engine design enough to know if that is prudent.

Yup. A useable php_startup_extensions() would sure be nice. Currently a working php_module_startup() would be sufficient for me, though ;-)

NOTE: I think it is also possible that if you add your custom extension to the php/ext directory that the build scripts will automatically pickup your extension and add its zend_module_entry to the generated main/internal_functions.c file. Checkout http://www.zend.com/apidoc/zend.build.php for more info.

In my case, the PHP extensions are part of a bigger picture and recompiling PHP would not fit very well in existing build processes. We are uing PHP to provide a web-based interface to a server software written in C++. So the "core part" is the C++ software here... Anyway, is there anything I can do to get this fixed in CVS? Would a patch have a chance to be applied? Regards, Norbert