On Wed, 2 Jan 2019 at 17:12 Christoph M. Becker <cmbecke...@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 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. > 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’t the case here. Unless I’m missing something, a code as simple as $x = 3.99; print “Price: $x”; would be affected. So, I think it has a much bigger impact than the UVS incompatibility, it’s 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 directive? 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’s 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’t commit to actually removing it at any time by officially deprecating it... Zeev
