Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103668
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>
In-Reply-To: <CAJHtznzzBvx9Dc5YPGT6kU97doCj0O2FxGGjnTNh4Pv2-Pucxg@mail.gmail.com>
Date: Wed, 2 Jan 2019 17:11:03 +0100
Message-ID: <CAF+90c_i7802QYeBUkgyc81Yv2ASzSHYqxNrObcA+TxA_b_46A@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000082c53a057e7be525"
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000082c53a057e7be525
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski <zeev@php.net> wrote:

>
>
> On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev <smalyshev@gmail.com>
>> wrote:
>>
>> We have a rather hard policy against ini options that influence language
>> behavior. Locale-dependent language behavior is essentially the same
>> issue,
>> just worse due to the mentioned issues, in particularly lack of
>> thread-safety and the possibility that the locale is changed by
>> third-party
>> libraries at runtime.
>>
>> We have removed existing ini flags controlling language behavior in the
>> past. I would say these removals were much more significant than what is
>> proposed here, but we did them anyway, and I think we are now in a better
>> place for it.
>>
>
> 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 place
> where a floating number (which could come from anywhere, so not very easy
> to track) is used in a string context (which too can happen in countless
> 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 disputing
> 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).
>
> 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.
>
> My 2c.
>
> Zeev
>

I don't expect this to be a particularly large issue for two reasons:

1. Not many people use this. I'm sure that there *are* people who use this
and use it intentionally, but I've only ever seen reference to this issue
as a bug or a gotcha.
2. Even if somebody is using this functionality, the only thing that's
going to happen is that their number display switches from 1,5 to 1.5.
That's a minor UX regression, not a broken application. It's something that
will have to be fixed, but it's also not critical, and for a legacy
application one might even not bother.

I think we should just put this to an RFC vote. We regularly have these
types of discussions, and people just disagree about level of anticipated
BC break relative to benefit of the change.

Nikita

--00000000000082c53a057e7be525--