3 ms·

The article mentions a use case for that: > What I found is that this is common in embedded and kernel code as a halt-on-error pattern. When a fatal error occu

The article mentions a use case for that: > What I found is that this is common in embedded and kernel code as a halt-on-error pattern. When a fatal error occurs and there’s no operating system to exit to, you simply stop:

account42 14d ago
Low level code can and should use assembly to get the precise effect they desire in these cases.
- mdspan 14d ago
  That would be pretty cumbersome though. If you're targeting N different architectures, you would have to write N different assembly blocks.
- rcxdude 14d ago
  I shouldn't need to drop to assembly to get an infinite loop that works!
- echoangle 14d ago
  Why not just allow infinite loops instead of having me write assembly for it though?
  - account42 14d ago
    Because a compiler being allowed to assume that a loop always terminates gives it more room to optimize the 99% of loops that aren't supposed to run until the heat death of the universe.
    - echoangle 14d ago
      Or you could just detect while loops with constant condition (like the C standard) and not touch any programs that don't exhibit UB while allowing infinite loops for other use cases at zero runtime cost and negligible compile cost.
pdonis 14d ago
If this is a genuine use case, I wonder why the language can't just introduce a built-in function for it. For example, std::get_stuck_here(). Then the compiler would know not to optimize this away. The implementation under the hood could still be an infinite loop, but the compiler would not have to guess why it's there.
- sigbottle 14d ago
  __asm__ __volatile("hlt"); when doing quick and hacky debugging could work
- gpderetta 14d ago
  one could already add loads off a volatile and portably prevent the loop from being optimized. But there was already a lot of existing embedded code that had this sort of loop, (and more will be written as it is an existing idiom) which the committee wanted to un-break.

account42 14d ago

Low level code can and should use assembly to get the precise effect they desire in these cases.

mdspan 14d ago
That would be pretty cumbersome though. If you're targeting N different architectures, you would have to write N different assembly blocks.
rcxdude 14d ago
I shouldn't need to drop to assembly to get an infinite loop that works!
echoangle 14d ago
Why not just allow infinite loops instead of having me write assembly for it though?
- account42 14d ago
  Because a compiler being allowed to assume that a loop always terminates gives it more room to optimize the 99% of loops that aren't supposed to run until the heat death of the universe.
  - echoangle 14d ago
    Or you could just detect while loops with constant condition (like the C standard) and not touch any programs that don't exhibit UB while allowing infinite loops for other use cases at zero runtime cost and negligible compile cost.

pdonis 14d ago

If this is a genuine use case, I wonder why the language can't just introduce a built-in function for it. For example, std::get_stuck_here(). Then the compiler would know not to optimize this away. The implementation under the hood could still be an infinite loop, but the compiler would not have to guess why it's there.

sigbottle 14d ago
__asm__ __volatile("hlt"); when doing quick and hacky debugging could work
gpderetta 14d ago
one could already add loads off a volatile and portably prevent the loop from being optimized. But there was already a lot of existing embedded code that had this sort of loop, (and more will be written as it is an existing idiom) which the committee wanted to un-break.