I agree with you that the codeset conversion functions should be there
by default (iconv and recode seem to have patchy/variable support on
different platforms; mbstring is reliable since we know exactly what is
supported in there).

I've been using the conversion functions of mbstring in production for
around 2 years now - I've never had a problem with them, so they are
more than stable IMO.

I think disabling mbstring by default would be a not-very-productive
step backwards, but I'm happy to compromize:

The issue is with the function table hacking, so why not either:

 o #ifdef it out and use a configure option to enable the potentially
   dangerous functionality.

 o Provide a zend-api for overloading function entries.
   This was something that came up a while ago on php-dev when
   the namespace purists were trying to ditch the _() function
   in the gettext extension.

   it might look something like this:

   int _zend_overload_function(char *func_name,
     void (*handler)(INTERNAL_FUNCTION_PARAMETERS),
         long apino TSRMLS_DC);

   #define zend_overload_function(func_name, handler) \
     _zend_overload_function((func_name), (handler), \
            ZEND_EXTENSION_API_NO TSRMLS_CC)

   In this way, _zend_overload_function can check to see which extension
   API is being used and then bail if it doesn't match (although this
   could be caught more generally by the module version info).

   More importantly, we can hide the gory details of the function table
   hash and implement the overload in a safe way.

--Wez.

On Thu, 7 Nov 2002, Marcus Boerger wrote:

> To make php be easier usable in non US-ASCII (127chars) environments
> especially those requiring UCS-2, UTF-8 or other any character mapping
> other than iso-8859-1 or -15 we should more likly try to integrate mbstring
> fully in php. As long as we cannot or want not make it a core component
> such as ext/standard we should enable it by default.
>
> And it do not see why it is dangerous or why it should harm any test?
> All hose mbstring settings affecting the tests are no set in such a way
> that activating mbstring cannot harm AND mbstring is deply tested for
> its own. When currently any test is affected by mbstring this should be
> reported so we can adjust test settings!
>
> marcus
>
> At 16:04 07.11.2002, Andrei Zmievski wrote:
> >At the PHP Conference in Germany several of us have discussed the
> >current state of mbstring and there was a proposal to not have it
> >enabled by default for 4.3.0 release. It seems that the extension
> >attempts to do "magic" stuff by overloading functions in the executor
> >globals and, as Thies said, that could be dangerous. Also, doesn't it
> >affect run-tests.php script currently?
> >
> >Comments are welcome.



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to