Comment Re:Watcom was great. How about today? (Score 1) 307
Heh, there's even more than that:
return (n && 1 == 0) ? 1 : -1;
Let's assume this actually reads n & 1, because that's obviously what was meant (this same argument would apply for && as well):
return (n & 1 == 0) ? 1 : -1;
Now, "==" needs to have an equality-expression on the left hand side. & does not count as an equality-expression, so a compiler is not allowed to parse the above as
return ( (n & 1) == 0 ) ? 1 : -1;
1, however, does count as an equality-expression, so in fact the compiler must interpret this as:
return ( n & (1 == 0) ) ? 1 : -1;
which is, of course:
return (n & 0) ? 1 : -1; ->
return 0 ? 1 : -1; ->
return -1;
This can be found in ISO/IEC 9899:1999 (C99), 6.5.9 and 6.5.10.
Of course, this isn't really important in the grand scheme of things, just thought I'd point it out... :)
In all reality, the way the standard specifies parsing for this is wrong, logically. K&R2, page 3: "Some of the operators have the wrong precedence". Check out this posting to see why.
return (n && 1 == 0) ? 1 : -1;
Let's assume this actually reads n & 1, because that's obviously what was meant (this same argument would apply for && as well):
return (n & 1 == 0) ? 1 : -1;
Now, "==" needs to have an equality-expression on the left hand side. & does not count as an equality-expression, so a compiler is not allowed to parse the above as
return ( (n & 1) == 0 ) ? 1 : -1;
1, however, does count as an equality-expression, so in fact the compiler must interpret this as:
return ( n & (1 == 0) ) ? 1 : -1;
which is, of course:
return (n & 0) ? 1 : -1; ->
return 0 ? 1 : -1; ->
return -1;
This can be found in ISO/IEC 9899:1999 (C99), 6.5.9 and 6.5.10.
Of course, this isn't really important in the grand scheme of things, just thought I'd point it out...
In all reality, the way the standard specifies parsing for this is wrong, logically. K&R2, page 3: "Some of the operators have the wrong precedence". Check out this posting to see why.
