5 ms·

TLDR: For almost 1/6 of a century, the C++ standards broke the simplest infinite loop and only just recently fixed it. Idiots! Don’t they really that peopl

TLDR: For almost 1/6 of a century, the C++ standards broke the simplest infinite loop and only just recently fixed it. Idiots! Don’t they really that people write real programs to solve real problems? This isn’t a theoretical academic exercise!

bryanlarsen 14d ago
They also realized that people choose compilers based on performance benchmarks, and that insane optimizations let them win.
- vlovich123 14d ago
  Until Rust proved actually you can get really good or better performance if the language itself is better. I really don’t know how C++ digs itself out of the UB hole it has dug.
  - bryanlarsen 14d ago
    Probably by working together with Rust. Eliminating undefined behavior from unsafe Rust is a big deal for the Rust community at the moment. And given that most unsafe rust code exists to call into C or C++, concepts like pointer provenance need to be extended. And proper pointer provenance guarantees can both decrease UB and increase optimization potential. IIUC, my understanding is shallow.
    - nicoburns 14d ago
      This particular case is likely an example of that. Rust used to have this problem, but it wasn't ever intended to. So IIRC it got fixed in LLVM for Rust, and this is probably now C++ taking advantage of that.
    - vlovich123 14d ago
      That's a niche level thing that helps in some scenarios, and generally not as much for C++ which is much more weakly typed than Rust is. Weak typing + static typing is why safety problems in C++ are going to be really difficult to fix without fundamentally changing the language.
      - bryanlarsen 14d ago
        I expect some changes to the language from this direction, some way to attach provenance information or limitations to a pointer. Presumably through a #pragma at first. Strict typing in the C++ sense, not the Rust sense. An annotation like "volatile". Pointer provenance is just one example, there are others.
Sharlin 14d ago
The argument is that an infinite loop without side effects isn't a real program. It's not useful for anything except wasting cycles.
- kibwen 14d ago
  And unfortunately that argument would be incorrect, because not only is there a realistic chance of hitting this on embedded systems, the fact that LLVM baked this into its low-level semantics resulted in miscompilations in Rust for a time, where `loop {}` is a valid way to implement a diverging function: https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728
- nh2 14d ago
  Of course the infinite loop should run as expected. It breaks the most fundamental debugging expectations (such as "delete code until problem disappears") if the fundamental, minimal building blocks of a language, when on their own, do random rubbish. To understand a program that does something, better first understand a program that does nothing. As a fan of sensible analogies: You put a salad bowl with vinegar into the fridge and notice that when you do that, the fridge stinks afterwards. You try again without the vinegar, then without the salad. In C++ world, upon receiving the empty bowl, the fridge detonates ("it is not useful"), blowing up your house. That is not OK.
  - Jaxan 14d ago
    But if you program a for loop computing the sum from 1 to n, this also gets replaced by a constant (unless you build in debug mode). Why would an empty loop be different?
    - vlovich123 14d ago
      I think the argument is that the equivalent of an infinite loop would be a halt / abort instruction, not a complete removal of the loop and continue running anything else.
deleted 14d ago
[deleted]
bluGill 14d ago
You are an idiot if you write an infinite loop. An infinite loop is a waste of CPU cycles and energy when run. If it wasn't so hard to detect (the trivial cases are easy, but it gets hard quickly) I'd say the program should fail to compile.
- echoangle 14d ago
  And how would you generate assembly to keep a microcontroller idle then?
  - bluGill 14d ago
    You call the CPU halt instruction.
    - echoangle 14d ago
      What if my CPU doesn't have that? I don't think Atmel Microcontrollers do for example.
      - bluGill 14d ago
        Better CPU selection. Embedded almost always have power requirements and you need to put your CPU into a low power mode not a loop which is running fast. You can also design your hardware such that you can turn the power off completely in these cases (or perhaps reboot). Now that I think of it, a different project (I worked just down the aisle, but I wasn't on it) solved a lot customer complaints by turning all the "while(1);" loops into blink an error code - which since it does IO is defined behavior. Which probably is the correct answer to your question - don't just spin doing nothing, spin in such a way that the user has a clue why nothing is working (and in turn you can find out and perhaps fix real world bugs)
        dare944 14d ago
        This is myopic. In many cases it takes time, and sometimes considerable programming effort, to enter and exit low power modes. So you don't do it willy-nilly; you do it when you believe the system has quiesced. That means, on a purely interrupt driven system that is not yet ready to sleep, the code may very well be spinning in an empty infinite loop somewhere. There's no need to inform the "user" because there's nothing wrong with the system. Its simply waiting until the benefit of sleeping outweighs the cost of getting there.
Panzerschrek 14d ago
> the simplest infinite loop An infinite loop which does nothing is practically useless. So, compilers optimize it out. That's the whole philosophy of modern compilers - to reduce execution time by preserving semantics. In case of an infinite loop elimination it's an optimization making code infinite times faster.
- chrystalkey 13d ago
  But also very different. If code below this loop executes after elimination and wouldnt have before, that is a very significant change in semantics

bryanlarsen 14d ago

They also realized that people choose compilers based on performance benchmarks, and that insane optimizations let them win.

vlovich123 14d ago
Until Rust proved actually you can get really good or better performance if the language itself is better. I really don’t know how C++ digs itself out of the UB hole it has dug.
- bryanlarsen 14d ago
  Probably by working together with Rust. Eliminating undefined behavior from unsafe Rust is a big deal for the Rust community at the moment. And given that most unsafe rust code exists to call into C or C++, concepts like pointer provenance need to be extended. And proper pointer provenance guarantees can both decrease UB and increase optimization potential. IIUC, my understanding is shallow.
  - nicoburns 14d ago
    This particular case is likely an example of that. Rust used to have this problem, but it wasn't ever intended to. So IIRC it got fixed in LLVM for Rust, and this is probably now C++ taking advantage of that.
  - vlovich123 14d ago
    That's a niche level thing that helps in some scenarios, and generally not as much for C++ which is much more weakly typed than Rust is. Weak typing + static typing is why safety problems in C++ are going to be really difficult to fix without fundamentally changing the language.
    - bryanlarsen 14d ago
      I expect some changes to the language from this direction, some way to attach provenance information or limitations to a pointer. Presumably through a #pragma at first. Strict typing in the C++ sense, not the Rust sense. An annotation like "volatile". Pointer provenance is just one example, there are others.

Sharlin 14d ago

The argument is that an infinite loop without side effects isn't a real program. It's not useful for anything except wasting cycles.

kibwen 14d ago
And unfortunately that argument would be incorrect, because not only is there a realistic chance of hitting this on embedded systems, the fact that LLVM baked this into its low-level semantics resulted in miscompilations in Rust for a time, where `loop {}` is a valid way to implement a diverging function: https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728
nh2 14d ago
Of course the infinite loop should run as expected. It breaks the most fundamental debugging expectations (such as "delete code until problem disappears") if the fundamental, minimal building blocks of a language, when on their own, do random rubbish. To understand a program that does something, better first understand a program that does nothing. As a fan of sensible analogies: You put a salad bowl with vinegar into the fridge and notice that when you do that, the fridge stinks afterwards. You try again without the vinegar, then without the salad. In C++ world, upon receiving the empty bowl, the fridge detonates ("it is not useful"), blowing up your house. That is not OK.
- Jaxan 14d ago
  But if you program a for loop computing the sum from 1 to n, this also gets replaced by a constant (unless you build in debug mode). Why would an empty loop be different?
  - vlovich123 14d ago
    I think the argument is that the equivalent of an infinite loop would be a halt / abort instruction, not a complete removal of the loop and continue running anything else.

deleted 14d ago

[deleted]

bluGill 14d ago

You are an idiot if you write an infinite loop. An infinite loop is a waste of CPU cycles and energy when run. If it wasn't so hard to detect (the trivial cases are easy, but it gets hard quickly) I'd say the program should fail to compile.

echoangle 14d ago
And how would you generate assembly to keep a microcontroller idle then?
- bluGill 14d ago
  You call the CPU halt instruction.
  - echoangle 14d ago
    What if my CPU doesn't have that? I don't think Atmel Microcontrollers do for example.
    - bluGill 14d ago
      Better CPU selection. Embedded almost always have power requirements and you need to put your CPU into a low power mode not a loop which is running fast. You can also design your hardware such that you can turn the power off completely in these cases (or perhaps reboot). Now that I think of it, a different project (I worked just down the aisle, but I wasn't on it) solved a lot customer complaints by turning all the "while(1);" loops into blink an error code - which since it does IO is defined behavior. Which probably is the correct answer to your question - don't just spin doing nothing, spin in such a way that the user has a clue why nothing is working (and in turn you can find out and perhaps fix real world bugs)
      - dare944 14d ago
        This is myopic. In many cases it takes time, and sometimes considerable programming effort, to enter and exit low power modes. So you don't do it willy-nilly; you do it when you believe the system has quiesced. That means, on a purely interrupt driven system that is not yet ready to sleep, the code may very well be spinning in an empty infinite loop somewhere. There's no need to inform the "user" because there's nothing wrong with the system. Its simply waiting until the benefit of sleeping outweighs the cost of getting there.

Panzerschrek 14d ago

> the simplest infinite loop An infinite loop which does nothing is practically useless. So, compilers optimize it out. That's the whole philosophy of modern compilers - to reduce execution time by preserving semantics. In case of an infinite loop elimination it's an optimization making code infinite times faster.

chrystalkey 13d ago
But also very different. If code below this loop executes after elimination and wouldnt have before, that is a very significant change in semantics