No offense, but it took you four hours to chase down a syntax error? If it survived long enough to see that kind of debugging effort, it was almost certainly dead code; seems like a unit test would have caught it before the first commit. And what compiler are you using? GCC certainly will issue warnings when the result of a = operator is used in a boolean context.
"No offence", yes, always a good way to start one's post! I think you missed out the "just saying", though. You need that too.
'=' vs '==' is not a syntax error. Consider "x=y=z" vs "x=y==z". And it's in somebody else's code. And they wrote it 2 months ago, but the programmer who's using it has only just started working with it. And they are super busy and don't have time to look at it. And it sort of looks like the problem is in the code you changed last week.
You can easily lose 4 hours over this stuff... have some imagination ;)
I'm just sayin', but this is a ridiculous strawman. (Well, you're right that it's not a syntax error in the sense of compiler output. I should have been more precise and called it a "syntax goof" instead.)
I addressed the "someone else wrote it two months ago" point above: If that happened, and this was in the code, it was dead code for two months, because it clearly couldn't have been running correctly. That's a process problem, not a syntax issue, and the appropriate fix is clearly not to modify the syntax of the language.
(Edit for ctdonath: good grief. 1.) the reply was to to3m's post, not yours. 2.) The "two months" thing comes straight out of his example, please read it. 3.) It was a JOKE, based on his chiding me for language. 4.) Why are you still flaming about this?)
"two months ago" is your own straw man. You made that up.
I'd written the code the day before, and it was failing a pre-commit unit test. As I posted elsewhere, this kind of "forgot the second =" error can compile without warning, esp. within a complex evaluation. The process was running fine, as it caught the existence of the logic error early. That it took hours to find was a matter of tracing symptoms back to cause in an embedded system not easily debugged when running.
One could make a valid argument that this is a problem of language syntax, as everyone has been bit by the = vs == difference. As such, and in line with this thread OP, you'd think a new popular language would learn from that mistake and would not throw === into the mix as a solution to an even more obscure problem (casting a string to a float? really?).
$ echo 'int foo(int x, int y, int p) { if(x=y&&p) return -1; return 0; }' > test.c
$ gcc -Wall -c test.c
test.c: In function ‘foo’:
test.c:1:1: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
This warning has been there since at least gcc 2.x, I believe.
I'm not making fun of you, really. But seriously: if you are spending 4 hours chasing bugs that can be trivially found by turning warnings on in your compiler, you have some process issues unrelated to C or PHP syntax.
Yes, and that is because "(x == y) && p" should be written as"x == y && p" according to gcc. If you add the brackets gcc takes that as a sign that you really wanted to do an assignment.
