Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Zeev Suraski 

At 20:35 15-08-01, Daniel Beulshausen wrote:
>isn't that exactly what i meant in my first mail? :)

I'm thick ;)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Daniel Beulshausen 

At 20:23 15.08.2001 +0300, Zeev Suraski wrote:
>At 20:20 15-08-01, Daniel Beulshausen wrote:
>>At 19:33 15.08.2001 +0300, Zeev Suraski wrote:
>>>At 18:40 15-08-01, Daniel Beulshausen wrote:
At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
>At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>>Is 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 :)

no i just looked, they are (i.e. sapi_read_standard_form_data in the 
fdf extension)
>>>
>>>They are what? :)
>>
>>breaking && using exported SAPI_POST_* functions.
>>i conclude, they still should get exported. :)
>
>Why?  Are modules using any SAPI_POST functions which are defined in 
>PHP?  If they are, we should probably change the

yep.

>SAPI_POST_HANDLER definition not to include SAPI_API, and add the SAPI_API 
>explicitly before those functions which are referenced by modules.

isn't that exactly what i meant in my first mail? :)
we would use
SAPI_API SAPI_POST...
to export them and extensions should use
PHP_EXT_API SAPI_POST...
if they want to export their functions.

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Zeev Suraski 

At 20:20 15-08-01, Daniel Beulshausen wrote:
>At 19:33 15.08.2001 +0300, Zeev Suraski wrote:
>>At 18:40 15-08-01, Daniel Beulshausen wrote:
>>>At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>Is 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 :)
>>>
>>>no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf 
>>>extension)
>>
>>They are what? :)
>
>breaking && using exported SAPI_POST_* functions.
>i conclude, they still should get exported. :)

Why?  Are modules using any SAPI_POST functions which are defined in 
PHP?  If they are, we should probably change the SAPI_POST_HANDLER 
definition not to include SAPI_API, and add the SAPI_API explicitly before 
those functions which are referenced by modules.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Daniel Beulshausen 

At 19:33 15.08.2001 +0300, Zeev Suraski wrote:
>At 18:40 15-08-01, Daniel Beulshausen wrote:
>>At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
>>>At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
Is 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 :)
>>
>>no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf 
>>extension)
>
>They are what? :)

breaking && using exported SAPI_POST_* functions.
i conclude, they still should get exported. :)

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Zeev Suraski 

At 18:40 15-08-01, Daniel Beulshausen wrote:
>At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
>>At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>>>Is 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 :)
>
>no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf 
>extension)

They are what? :)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Daniel Beulshausen 

At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
>At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>>Is 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 :)

no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf 
extension)

daniel

>daniel
>
>>At 17:58 15-08-01, Daniel Beulshausen wrote:
>>>hi
>>>
>>>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 - [EMAIL PROTECTED]
>>>using php on windows? http://www.php4win.de
>>>
>>>
>>>--
>>>PHP Development Mailing List 
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>>
>>--
>>Zeev Suraski <[EMAIL PROTECTED]>
>>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
>/*--
>daniel beulshausen - [EMAIL PROTECTED]
>using php on windows? http://www.php4win.de
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Daniel Beulshausen 

At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>Is 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

>At 17:58 15-08-01, Daniel Beulshausen wrote:
>>hi
>>
>>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 - [EMAIL PROTECTED]
>>using php on windows? http://www.php4win.de
>>
>>
>>--
>>PHP Development Mailing List 
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>--
>Zeev Suraski <[EMAIL PROTECTED]>
>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] SAPI_API glitch

2001-08-15 Thread Zeev Suraski 

Is 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)

At 17:58 15-08-01, Daniel Beulshausen wrote:
>hi
>
>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 - [EMAIL PROTECTED]
>using php on windows? http://www.php4win.de
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]