Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103667
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=BS5pIcpwQ22VMV+ETRovaiqB+cykSUai4AKQonFQ9xWqtxnQ+soIbM6aPD3QRz
	LKo7rN7UnJH2r5ps1En2sJepVGRQa+JJ9WhXzEL9LQPG6zSNCzEMq4C4m6O6hM5C
	Hws3uDjHZzp4TJUtVhIspo/uPutk4IZR5u56rAdI+IvXs=;
MIME-Version: 1.0
References: <a7761c2f-5716-279b-d701-5f588b856277@gmx.de> <dbfae3d5-e317-f680-9fe6-240ab142d105@gmail.com> <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de> <a0e50789-10c0-263d-f6a7-56486d7bb318@gmail.com> <CAF+90c-2ama6LBDY0xQKN1oPV-YMaY2==SSWk_hSstc40y9NWQ@mail.gmail.com> <CAJHtznzzBvx9Dc5YPGT6kU97doCj0O2FxGGjnTNh4Pv2-Pucxg@mail.gmail.com> <574c2a6f-9ca7-7aa8-4bd9-a7191b27cb31@gmx.de>
In-Reply-To: <574c2a6f-9ca7-7aa8-4bd9-a7191b27cb31@gmx.de>
Date: Wed, 2 Jan 2019 17:51:17 +0200
Message-ID: <CAJHtznyK7z64GYFOg1tuMAy6dfA2oLOCf_JBpYLS4iSG7H_yMQ@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>,  Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000025a744057e7ba135"
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: zeev@php.net (Zeev Suraski)

--00000000000025a744057e7ba135
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2 Jan 2019 at 17:12 Christoph M. Becker <cmbecker69@gmx.de> wrote:

> On 02.01.2019 at 12:32, Zeev Suraski wrote:
>
> > Unless I'm missing something, changing this behavior would require a
> full,
> > line-by-line audit of the code - with no Search & Replace patterns that
> can
> > find these instances in any reasonable level of reliability.  Every pla=
ce
> > where a floating number (which could come from anywhere, so not very ea=
sy
> > to track) is used in a string context (which too can happen in countles=
s
> > different contexts, virtually impossible to track) would be affected.
> > Sounds pretty nightmarish to me.  I for one fail to recall a behavioral
> > change that was quite as significant as this one in terms of the
> complexity
> > of finding instances that must be updated.  Like Stas, I'm not disputin=
g
> > that this is not an ideal behavior or that we'd do it differently if we
> > were starting from scratch - but I also agree with him that it's pretty
> > much out of the question to simply change it at this point.
> >
> > Can you point out a change you believe is as or more significant than
> this
> > one that we did?  I think the only one that comes close is
> > magic_quotes_runtime, and even that was significantly easier to handle =
in
> > terms of the cost of auditing the code (again, unless I'm missing
> > something, which is of course very much a possibility).
>
> Wasn't the removal of register_globals a similar change?  Not so long
> ago I've stumbled upon a script which counteracted this by extract()ing
> the superglobals manually (surely, a very bad practise, but at least
> some kind of workaround to keep legacy scripts going).  However, the
> introduction of =E2=80=9CUniform Variable Syntax=E2=80=9D[1] may have cau=
sed similar
> issues; likely without any possible workaround.
>

Well, the removal of register_globals was a very big deal - and was done
for arguably much more pressing reasons (security).  So I wouldn't refer to
it as basis to illustrate that this isn't a big deal...  That said - as you
pointed out yourself, there was a very easy workaround for those that
didn't want or couldn't afford to do a full code audit - a few lines of
user and code that emulated it.

Regarding Uniform Variable Syntax - the cases where the behavior changed
there were truly edge cases, that nobody in his right mind should be using
anyway, and that can probably also be searched for using a clever regex.
This isn=E2=80=99t the case here.  Unless I=E2=80=99m missing something, a =
code as simple
as $x =3D 3.99; print =E2=80=9CPrice:  $x=E2=80=9D; would be affected.

So, I think it has a much bigger impact than the UVS incompatibility, it=E2=
=80=99s
much more difficult to find, and does not have a userland workaround unless
we introduce a language level one.

>
> > The solution for this *might* be a very unholy one - actually going
> against
> > our practices adding a new INI entry to would disable the
> locale-awareness
> > for float->string conversions;  But for upgrade considerations, I don't
> > think we can even consider simply changing this behavior and forcing
> > virtually everyone using a non-dot decimal separator to undergo a full
> code
> > audit.
>
> Would it be a sensible option to trigger a warning or notice whenever a
> float is converted to string yielding a different result than before,
> using an ini directive to control this?  Or perhaps even throw a
> deprecation notice in this case, without even introducing an ini directiv=
e?


It would be technically possible, but given the context these conversions
often occur in I think it would look awful...   Also, one would have to run
their software through all possible code flows in order to know for sure
it=E2=80=99s safe to turn it off and move to the new behavior.  And legend =
has it,
that not all PHP users (or developers in general) have 100% testing
coverage :)

If we do end up adding a new INI entry - maybe it can be a tristate -
legacy, legacy+notice, or new.  Just a thought.  And I wouldn=E2=80=99t com=
mit to
actually removing it at any time by officially deprecating it...

Zeev

--00000000000025a744057e7ba135--