Re: [RFC] Multibyte char handling

On Thu, Jan 16, 2014 at 11:47 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Nikita, > > On Fri, Jan 17, 2014 at 7:38 AM, Nikita Popov <nikita.ppv@gmail.com> 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