On 02.01.2019 at 12:32, Zeev Suraski wrote: > On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov <nikita....@gmail.com> wrote: > >> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev <smalys...@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).
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 “Uniform Variable Syntax”[1] may have caused similar issues; likely without any possible workaround. > 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 directive? [1] <https://wiki.php.net/rfc/uniform_variable_syntax> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
