651
More code = more better (lemmy.zip)
submitted 7 months ago by to c/programmer_humor@programming.dev
92 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 7 months ago* (1 child)

An infinite loop canot be ruled out in the last case, so a compiler couldn't optimize this away without potentially changing the program behavior.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 7 months ago (1 child)

    Infinite loops are often weird though. They could be seen as undefined behavior and the compiler may do whatever it feels like.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 7 months ago (1 child)

    How could an infinite loop be considered UB?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 7 months ago

    Even though this isn't C, but if we take from the C11 draft §6.8.5 point 6 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):

    An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate

    "new Random().nextInt()" might perform I/O though so it could still be defined behavior. Or the compiler does not assume this assumption.

    But an aggressive compiler could realize the loop would not terminate if x does not become 10 so x must be 10 because the loop can be assumed to terminate.

  • permalink
  • fedilink
  • source
  • parent