• abbadon420@lemm.ee
    link
    fedilink
    arrow-up
    32
    arrow-down
    1
    ·
    1 year ago

    The third one is just (x=x+1), because the middle bit is just always false and can be ignored.

      • rhpp@programming.dev
        link
        fedilink
        arrow-up
        11
        ·
        1 year ago

        Still false, thanks to compiler optimizations. Remember that integer overflow is UB. (unless you’re using unsigned int or a programming language which strictly defines integer overflow, possibly as an error)

        P.S.: Assuming this is C/C++

        • chellomere@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 year ago

          No, because it’s UB, the compiler is free to do whatever, like making demons fly out of your nose

  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    1
    ·
    edit-2
    1 year ago
    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.)

    • xthexder@l.sw0.com
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      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)

      • mormegil@programming.dev
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        1 year ago

        It will not “overflow”. Signed integer overflow is undefined behavior. The compiler could remove the whole loop or do anything else imaginable (or not).

          • BatmanAoD@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Languages with dynamic typing and implicit large-integer types, such as Python and Ruby, generally just convert to that large-integer type.

            I figured Java would probably define the behavior in the JVM, but based on a quick web search it sounds like it probably doesn’t by default, but does provide library methods to add or subtract safely.

            Rust guarantees a panic by default, but provides library methods for wrapping, saturating, and unchecked (i.e. unsafely opting back in to undefined behavior).

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 year ago

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

        • xthexder@l.sw0.com
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          The backticks worked in the preview, and showed up correctly to start, but there must be a bug in the lemmy ui, since now it’s double-escaped. No idea /shrug

  • nybble41@programming.dev
    link
    fedilink
    arrow-up
    12
    ·
    1 year ago

    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.