Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 156.151.31.81 as permitted sender)
Message-ID: <1429186803.18620.18.camel@kuechenschabe>
To: Marc Bennewitz <dev@mabe.berlin>
Cc: internals@lists.php.net
Date: Thu, 16 Apr 2015 14:20:03 +0200
In-Reply-To: <551C3876.5000004@mabe.berlin>
References: 
	<CA+kxMuSvxRq-AvjQSBUc-FiYdTrD_1X2SuQtjWRjTwAbcwWRoA@mail.gmail.com>
	 <551C3876.5000004@mabe.berlin>
Organization: Oracle Corporation - MySQL
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecate setlocale?
From: johannes.schlueter@oracle.com (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Wed, 2015-04-01 at 20:27 +0200, Marc Bennewitz wrote:
> > https://bugs.php.net/bug.php?id=3D69348 - breaks MySQL
> -> It's a bug and should be fixed (non locale based functionality)
> -> Couldn't this one be a security issue

No this is not a bug in this function and no not a security issue.

The user asks to escape a string and provides a double. The double is
therefore converted to a string according to PHP's rules and then
correctly escaped. Now PHP's rules are a bit unfortunate and might lead
to wrong data being stored.

=46rom MySQL perspective the correct usage is not to escape numeric types.
Those can be put in the query directly. (Code like
   $d =3D (double)$foo; $sql =3D "SELECT * FROM t WHERE d=3D$d";
is safe.) or maybe better use prepared statements.

Also mind: Locale not only has impact on number->string conversion but
also different string operations like uppercase/lowercase conversion:
(see Turkish i->I->y)

Revising locale might be a good idea, however not by removing a function
but by finding a way to make the behavior more explicit to the user.
Removing the function will cause trouble when interacting with external
libraries and programs which are locale dependent.

johannes
--=20
ORACLE Deutschland B.V. & Co. KG | Riesstra=C3=9Fe 25 | 80992 M=C3=BCnchen

Registergericht: Amtsgericht M=C3=BCnchen, HRA 95603
Komplement=C3=A4rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch=C3=A4ftsf=C3=BChrer: Alexander van der Ven, Astrid Kepper, Val Maher