I mean it could be right
I mean it could be right
I mean it could be right
When the metric is lines of code
When the company tries to be cheeky and starts to count characters instead
Rename c to completelyUnimportantVariableThatISoLongBecauseIGetPaidMore
The third one is just (x=x+1), because the middle bit is just always false and can be ignored.
++x;
The underutilized post pre increment operator.
for (int y = MIN_INT; y <= MAX_INT; y++) { if (y == x + 1) { x = y; } }
(Not sure there's a way to prevent Lemmy from escaping my left angle bracket. I definitely didn't type ampersand-el-tee-semicolon. You'll just have to squint and pretend. I'm using the default lemmy-ui frontend.)
y <= MAX_INT
will never be false, since the loop will overflow and wrap around to MIN_INT
(You can escape code with backticks
, and regular markdown rules)
It will not "overflow". Signed integer overflow is undefined behavior. The compiler could remove the whole loop or do anything else imaginable (or not).
Oh good call! What I was trying to do is more complex than I was thinking.
Hmmmmm.
int f = TRUE; for (int y = MIN_INT; f || y - 1 < y; y++) { f = FALSE; if (y == x + 1) { x = y; } }
(I should just test my code to make sure it works, but I haven't. Heh.)
Also, Lemmy escaped your angle bracket too. Back ticks don't seem to do the trick.
Block: <
Inline: <
Or were you suggesting back ticks for some other purpose? (I did use back ticks in my first post in this thread.)
I'm fairly certain that last one is UB in C. The result of an assignment operator is not an lvalue, and even if it were it's UB (at least in C99) to modify the stored value of an object more than once between two adjacent sequence points. It might work in C++, though.
That was my first thought when trying to figure out what it did
You forgot ++x
.