Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103666 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84831 invoked from network); 2 Jan 2019 18:40:07 -0000 Received: from unknown (HELO mout.gmx.net) (212.227.17.22) by pb1.pair.com with SMTP; 2 Jan 2019 18:40:07 -0000 Received: from [192.168.2.103] ([91.8.175.134]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lg5kl-1h81fK02yh-00pe0c; Wed, 02 Jan 2019 16:12:45 +0100 To: Zeev Suraski , Nikita Popov Cc: Stanislav Malyshev , PHP internals References: <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de> Message-ID: <574c2a6f-9ca7-7aa8-4bd9-a7191b27cb31@gmx.de> Date: Wed, 2 Jan 2019 16:12:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:523i+YXQ04PJ8QKMwTZQ8X14FRKA+FDZDwzuXehD4CLYOLcCOEb 0T6zmzsoOnRzTFODRsh5PUVqpTvhat95xDc176bDTV00jnKgcM3rBqzqH8Jcms578Kj2/7e 3kVTLXFKXdabVMqwFkNLYq5ARjwlBjzt78x6pYvjlSEwV4kePz6Rlq8anLfaA1am6x1Y98y HCFe3YNvOsvF32piUsJzQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+S4kc85oGTU=:Z0qZOnLzLoVdRns+BnfNOk /VVW7rECy40aLKWQubE5C+AvFHrF+s6m0ZyAB9E4Efg8678VHiIODe1q6pFsWCnJc92GJ0TrB sPLqBKoay1Z97vi/hFyiVeEGzC6wUqaj1TjkLR2AZndtd5ZqJCqrhJx3pplLx+R6SRt5IKlb1 Dsxkz1W43mgJIMPxVNhor9YTRL7mEFkDJF3uSBTubVeicrcsQsCqY4vQ6l0ljjEq4+H9y6N1K vGcv7oEreuvjvWIHfiuYYtc3Ex+lL3l2bPzKwace4AggZ+i0r0xtdYX0ZZtkRXenH+9Xx4CE6 MMvoBGnmxneAq5kPTdbsJMYiIOWMcyuMcFnNlpsL7rjkDKsnkBFHP0zBsc1IAcklz0BGaeDYY GEWLIOo4S9Pn1C/7ujUkJfPFDN1B3ruxRF7ekaS/p3m5WMURjiMGwqJDVAjRKkkrP5wEFdYMN Zi32Aebwf9LZD9AC79XsurgrAWGAkzDjbv6hgtpAsYk3b+wERUTxYm3wgfZOba9Z80IEwOfu0 3dGYYk7L7M0dAloVC5lboMUkt/wbJe3ytARYRvjrcJ5Am5FAEmXkaASW3G2Pfamncmq3xH9kM qCd+2Eix+OaZNtRBzs8MKCGqFMGwGMquNohHYGW2N6B0/feXxBvl4uRcxNstBQQT1XQRoCP3Q UC8ArnsC1bTavwywhrK1m4WTmt8qqAgftcadTpEx4PqDa8TPzzbEPWqZaOXCcFWWjAwUsoY2w E2psOe+z9FLILgfPh6DgP51EcEMmdBfjnVr1lnZkiCB8cz2SYxIcB2mhQEfxqGcN3bxERUxqb ZzRTBXlTiCanLLW5zPNWgpgslUrxw90CNJLQxor5TDX75nU6E/BBLn47CfDvJCFYDBQCuZdW5 inF+hkr8elCI8xwube26eq0UJQUtCp0QduAH7+3i1B13J6mBopeouhP0L+cRJw Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting From: cmbecker69@gmx.de ("Christoph M. Becker") On 02.01.2019 at 12:32, Zeev Suraski wrote: > On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov wrote: > >> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev >> 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] -- Christoph M. Becker