Reminds me of the days before ai assistants where people copy pasted code from forums and then you’d get quesitions like “I found this code and I know what every line does except this ‘for( int i = 0; i < 10; i ++)’ part. Is this someone using an unsupported expression?”
I mean i < 10 isn’t wrong as such, it’s just good practice to always use <= because in the INT_MAX case you have to and everything should be regular because principle of least astonishment: That 10 might become a #define FOO 10, that then might become #define FOO INT_MAX, each of those changes look valid in isolation but if there’s only a single i < FOO in your codebase you introduced a bug by spooky action at a distance. (overflow on int is undefined behaviour in C, in case anyone is wondering what the bug is).
…never believe anyone who says “C is a simple language”. Their code is shoddy and full of bugs and they should be forced to write Rust for their own good.
But your case is wrong anyways because i <= INT_MAX will always be true, by definition. By your argument < is actually better because it is consistent from < 0 to iterate 0 times to < INT_MAX to iterate the maximum number of times. INT_MAX + 1 is the problem, not < which is the standard to write for loops and the standard for a reason.
You’re right, that’s what I get for not having written a line of C in what 15 years. Bonus challenge: write foriini32::MIN..=i32::MAX in C, that is, iterate over the whole range, start and end inclusive.
(I guess the ..= might be where my confusion came from because Rust’s .. is end-exclusive and thus like <, but also not what you want because i32::MAX + 1 panics).
Would you be bold enough to write if (i++ == INT_MAX) break? The result of the increment is never used, but an increment is being done, at least syntactically, and it overflows, at least theoretically, so maybe (I’m not 100% sure) the compiler could be allowed to break out into song because undefined behaviour allows anything to happen.
Reminds me of the days before ai assistants where people copy pasted code from forums and then you’d get quesitions like “I found this code and I know what every line does except this ‘for( int i = 0; i < 10; i ++)’ part. Is this someone using an unsupported expression?”
i <= 9, you heathen. Next thing you’ll do isi < INT_MAX + 1and then the shit’s steaming.I’m cooked, see thread.
If it was correct it wouldn’t have been copied into the forums lmao
I mean
i < 10isn’t wrong as such, it’s just good practice to always use<=because in theINT_MAXcase you have to and everything should be regular because principle of least astonishment: That10might become a#define FOO 10, that then might become#define FOO INT_MAX, each of those changes look valid in isolation but if there’s only a singlei < FOOin your codebase you introduced a bug by spooky action at a distance. (overflow on int is undefined behaviour in C, in case anyone is wondering what the bug is).…never believe anyone who says “C is a simple language”. Their code is shoddy and full of bugs and they should be forced to write Rust for their own good.
But your case is wrong anyways because
i <= INT_MAXwill always be true, by definition. By your argument<is actually better because it is consistent from< 0to iterate 0 times to< INT_MAXto iterate the maximum number of times.INT_MAX + 1is the problem, not<which is the standard to write for loops and the standard for a reason.You’re right, that’s what I get for not having written a line of C in what 15 years. Bonus challenge: write
for i in i32::MIN..=i32::MAXin C, that is, iterate over the whole range, start and end inclusive.(I guess the
..=might be where my confusion came from because Rust’s..is end-exclusive and thus like<, but also not what you want becausei32::MAX + 1panics).for (int i = INT_MIN; ; i++) { ... if (i == INT_MAX) break;}Would you be bold enough to write
if (i++ == INT_MAX) break? The result of the increment is never used, but an increment is being done, at least syntactically, and it overflows, at least theoretically, so maybe (I’m not 100% sure) the compiler could be allowed to break out into song because undefined behaviour allows anything to happen.