Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103663
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=Jk1kIChiHP7pDHRfa6NsqQbfFuaSkuGHRrUupICTEZ3JIizKLO2gaYLz/2UPib
	vurZYH18l9zvxvuNilBxFjlb5q/ZSSQGVGssvckppKLkCI+I0Axfr5PqP3h980qM
	uzLw9TEjen33NMqHob7AXzLkDWkoN4jcxw1QhzRK5gg/M=;
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>
In-Reply-To: <CAF+90c-2ama6LBDY0xQKN1oPV-YMaY2==SSWk_hSstc40y9NWQ@mail.gmail.com>
Date: Wed, 2 Jan 2019 13:32:27 +0200
Message-ID: <CAJHtznzzBvx9Dc5YPGT6kU97doCj0O2FxGGjnTNh4Pv2-Pucxg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, "Christoph M. Becker" <cmbecker69@gmx.de>,  PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dff02e057e780016"
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: zeev@php.net (Zeev Suraski)

--000000000000dff02e057e780016
Content-Type: text/plain; charset="UTF-8"

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

--000000000000dff02e057e780016--