1350
How it started vs. How it's going
(lemmings.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Mar 2025
1350 points (99.8% liked)
Programmer Humor
34442 readers
212 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
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).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.