Re: SAPI_API glitch
| From: | Daniel Beulshausen | Date: | Wed, 15 Aug 2001 15:40:35 +0000 |
| Subject: | Re: SAPI_API glitch | ||
| References: | 1 2 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-63290@lists.php.net to get a copy of this message | ||
At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
At 18:20 15.08.2001 +0300, Zeev Suraski wrote:no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) danielIs there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do)not sure, but we can add it later if it breaks :)
daniel/*-- daniel beulshausen - daniel@php4win.de using php on windows? http://www.php4win.deAt 17:58 15-08-01, Daniel Beulshausen wrote:/*-- daniel beulshausen - daniel@php4win.de using php on windows? http://www.php4win.de -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.nethi currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, mbstring) they'll run into trouble, because they are defined as 'SAPI_API void ... my_handler'. this however doesn't work, because you'll need to define SAPI_EXPORTS (to export it) and are thus loosing the sapi_globals_id (which must be imported). nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) SAPI_POST_*_FUNC would avoid this glitch. anyone objects? daniel /*-- daniel beulshausen - daniel@php4win.de using php on windows? http://www.php4win.de -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/