Thread

1. account42 · 1789745601 · focus · HN ↗

   Unfortunate. There isn't ever a good reason to have an infinite loop so concerned compilers could have just diagnosed this as a warning.

   1. echoangle · 1789745988 · focus · HN ↗

      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:

      1. pdonis · 1789747764 · focus · HN ↗

         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.

         1. gpderetta · 1789770782 · focus · HN ↗

            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.

Unofficial Hacker News client; not affiliated with Y Combinator.