Hi Stas, Dmitry, I forgot to reply to Stas' message yesterday, sorry... But, there is no change in behavior here either as far as I know. For the code Stas quoted, with static vars (if that's what was being referred to), there's definitely not been a change (though its parser code was tweaked a bit), and there has never been a locale issue, and the operand negation happens at compile-time (as always).
The reason there should also be no change doing +/- at compile time now (out of static_scalar context) with constant values is because locale *does not affect* string to number conversion -- only '.' works as a decimal point in is_numeric_string() (maybe zend_strtod() too; didn't look), so there's no way the conversion could be different during runtime. :-) Now for going the other way, double to string, locale is honered, I believe? In that case, Dmitry, that would be another issue trying to do the full folding (with ZEND_CONCAT), with something like $a = 'abc ' . 1.23; So good thing it's left out for now! (Hmm, don't [some] optimizers do this folding? Maybe they haven't considered the locale issue...) But anyway, I don't think there are any worries about the current code and what has been done. Thanks, Matt ----- Original Message ----- From: "Dmitry Stogov" Sent: Sunday, August 31, 2008 > Hi Stas, > > We discussed this patch with Matt, and I allowed this change. > So it probably my fault (I missed run-time locale change possibility). > I don't think it is a really big issue, but it really may change > behavior of some scripts. > I think we should revert this patch, before we get complete solution for > compile-time expression evaluation (not in 5.3 of course). > > Thanks. Dmitry. > > Stanislav Malyshev wrote: > > Hi! > > > >> static $a = -'abc'; // 0 > >> static $b = +'abc'; // abc > >> $c = +'abc'; // 0 > >> } > > > > We could get into trouble here. Imagine: > > static $a = -'12.8'; > > > > This should be -12.8, but what if locale changes and . is no longer > > decimal separator? Moreover, what if locale changes between compile and > > runtime? We get entirely different code now. > > > >> Well, I don't know if it can be tossed in quickly at this time, but > >> there ya > >> go since I think it's pretty basic! ;^) > > > > I think it's not the feature that can be "tossed in quickly" - it can > > have some obscure side effects, as I described in my later emails. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
