Re: [VOTE] RFC: Multibyte Char Handling

From: Date: Tue, 28 Jan 2014 10:19:01 +0000
Subject: Re: [VOTE] RFC: Multibyte Char Handling
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-71664@lists.php.net to get a copy of this message
On Sun, 26 Jan 2014, Yasuo Ohgaki wrote: > Hi Nikita, > > On Sun, Jan 26, 2014 at 9:38 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > This RFC conflates the addition of a multibyte version of addslashes (in > > response to quoted CVE) with the replacement of the mbstring extension by a > > completely different implementation (and an incomplete one at that). Those > > two things have very little to do with each other and should not be covered > > in the same RFC and/or vote. > > The root cause of this issue is lack of multibyte aware functions that > relates to security. Yes, and the only way to address that properly is to make PHP support Unicode. This proposal adds layers of hacks to go around it - and although there is a possibility for broken data, I don't think it's worth doing. > I've wrote the RFC to compile current mbstring by default at first, > but it was withdrawn. The reason why is that mbstring is using LGPLed > libraries. As long as it is loaded as shared module, there would not > be issue. However, if these are compiled and used statically, LGPL > will be effective. > > To avoid this issue, mbstring would be better to replaced by mbstring-ng > and move mbstring to PECL for future release. > > I'll work on mbstring-ng so that it has all mbstring features. Until then, > we may have it as EXPERIMENTAL. We already have intl - why add another mbstring like function thing? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

« previous php.internals (#71664) next »