Re: Bug #1452 Updated: $i = $i++ fails

To make it clear, the reason it's left out from the C spec is to allow compilers to optimize stuff better, without limiting them to one possible solution only. Also, even if it wasn't like that, it's likely that the C spec would have resolved this conflict making i = i++ behave as nothing, and not i++, since from a compiler design point of view, this solution is MUCH more intuitive and allows a much easier and modular design of your parser. Zeev At 06:00 26/05/99 , Colin Putney wrote:

Jim Winstead wrote: You're making the strong assertions that the behavior you describe is "expected" and "intuitive". The construct we're talking about doesn't lead to bugs because of how PHP evaluates it, it IS a bug. Well, it's only a bug because of PHP's current behaviour. Don't get me wrong. It's clearly a bogus construct, and I'd be ashamed if it ever cropped up in code I'd written. But there's a difference between bad/inefficient/redundant code and code with syntax or logic errors. That's what makes Perl haiku and obfuscated C contests possible. The code posted with the original bug report had a logic error in it, causing an infinite loop. If PHP behaved differently, that same code would be merely inefficient and slightly embarrassing. I suppose I am making fairly strong assertions about what is "intuitive" or "expected." But I also think they're true. The guy that posted the bug in the first place wasn't totally out to lunch, despite his exposure to questionable code. I see no reason to pin down a defined behavior since if anything is obvious, it is that the construct is completely bogus, and to define its behavior limits future opportunities for possible code optimization. Now "limits future opportunities for possible code optimization" would be one of the good reasons I was looking for. Of course, Zeev is the one you have to convince, not me. :) Believe it or not, I'm not actually trying to convince anyone. To some extent, I'm playing devils advocate here. It *is* a bogus construct, and maybe newbies who make that error should get burned by it right away, so they don't carry a bad habit into the C world. But Zeev framed the question as an implementation decision which is left open by the C spec. Though he didn't say so specifically, I gather from his comments that a decision had been made during the implementation of PHP. I figure there's a fairly good argument for the opposite decision, and I'm curious as to the rational behind the decision that was made. I realize this is much ado about nothing and I'm on slightly thin ice here as I've never written a compiler or even contributed to the PHP source, but hey, this isn't your usual flame bait... ---------------------------------------------------------

Colin Putney                  colin@whistler.net
Bit Flinger                   (604) 932-0606 x21
Whistler Networks             http://www.whistler.net/

-- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net