On Thu, Jan 16, 2014 at 11:47 PM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Nikita,
>
> On Fri, Jan 17, 2014 at 7:38 AM, Nikita Popov <[email protected]> wrote:
>
>> No, I don't want a locale-based approach. I want the string functions to
>> stay as is. Multibyte variants of the functions can be added to the
>> multibyte extension.
>
>
> Creating mb_*() function would not solve security issues of
> multibyte char handling since multibyte aware functions are
> optional feature.
We never supported nor claimed that these functions are multi bytes
safe. However I actually fully understand that we should solve this
problem, in one way or another.
> However, it may work if PHP compiles mbstring by default and
> discourage use of addslashes()/var_export()/stripslashes()
> in favor of mb_*() variants.
I do not think we should discourage the use of these functions but
clearly document to rely on mb_* APIs as long as multi bytes support
is required.
I join other about not making any optional arguments in the existing
APIs, for a couple of reasons:
1. it does not solve anything as people still have to update their
code, and they won't unless maybe if they read the doc/changelog
2. It is really not a clean solution
3. we already have many duplicate functions in mb, it has worked well
so far and we can add the ones discussed here
The last question was about relying on locale. This is absolutely not
a solution. Locale has been proven to be totally unreliable, buggy and
unsafe. Let alone the total lack of real posix locale support on
Windows.
For anything related to locale, formats or encoding, we should rely on
intl (ICU) and not on systems's locale. This is the only way to be
portable, safe and updated.
Cheers,
Pierre