• kevincox@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    15 hours ago

    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.

    • barsoap@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      17 hours ago

      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::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).

        • barsoap@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          15 hours ago

          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.