3 ms·

You might ask why it's important that the first loop terminates since in this case the extra side effect would just be a dead store - but if the first loop does

by mitxela 26d ago

You might ask why it's important that the first loop terminates since in this case the extra side effect would just be a dead store - but if the first loop doesn't terminate then it's possible B is an invalid pointer and then accessing it during the first loop is UB when it shouldn't be. Making a nonterminating loop UB is the patch for this. The standard example is a linked list instead of an array because the compiler can't prove it never has a cycle.

CamperBob2 26d ago
The complaint I have is that for the sake of benchmark wars, UB has been retconned from "The code might not behave the way you want under certain conditions on certain platforms, hopefully you know what you're doing" to "The compiler can do anything it wants, including rickrolling the user." That is no longer undefined behavior in my book. That is defined behavior that just has an unusually-shitty definition. It's all moot anyway given other trends in progress, but... UB, bah humbug. Stop trying to fix problems that no one had. This is why people are clamoring to replace C/C++ with Rust and AI and whatever. The language needed to become more understandable and more predictable in everyday use, and instead it got worse.
- mitxela 26d ago
  Yes.
imtringued 26d ago
So you're saying the person you are responding completely failed to make their point clear? Why use a for loop with a bound as an example instead of while loops with linked lists? He or she can prompt an LLM for a better example so laziness doesn't count as an excuse.
- teo_zero 25d ago
  > Why use a for loop with a bound as an example instead of while loops with linked lists? I'm the author of the example. I wanted to keep it as simple as possible, and this is the most common form of for loop. I was sure that HN readers would be clever enough to "map" it to whatever they have in their mind that satisfy the undecidability of the condition. But since you're nitpicking, I haven't specified the types of i and n: i is uint8_t and n is uint32_t. Does it terminate? It depends on the value of n!

by mitxela 26d ago

CamperBob2 26d ago

The complaint I have is that for the sake of benchmark wars, UB has been retconned from "The code might not behave the way you want under certain conditions on certain platforms, hopefully you know what you're doing" to "The compiler can do anything it wants, including rickrolling the user." That is no longer undefined behavior in my book. That is defined behavior that just has an unusually-shitty definition. It's all moot anyway given other trends in progress, but... UB, bah humbug. Stop trying to fix problems that no one had. This is why people are clamoring to replace C/C++ with Rust and AI and whatever. The language needed to become more understandable and more predictable in everyday use, and instead it got worse.

mitxela 26d ago
Yes.

imtringued 26d ago

So you're saying the person you are responding completely failed to make their point clear? Why use a for loop with a bound as an example instead of while loops with linked lists? He or she can prompt an LLM for a better example so laziness doesn't count as an excuse.

teo_zero 25d ago
> Why use a for loop with a bound as an example instead of while loops with linked lists? I'm the author of the example. I wanted to keep it as simple as possible, and this is the most common form of for loop. I was sure that HN readers would be clever enough to "map" it to whatever they have in their mind that satisfy the undecidability of the condition. But since you're nitpicking, I haven't specified the types of i and n: i is uint8_t and n is uint32_t. Does it terminate? It depends on the value of n!