←back to thread

93 points endorphine | 1 comments | | HN request time: 0.204s | source
Show context
Brian_K_White ◴[] No.43536927[source]
They let the programmer be the ultimate definer of correctness.

They don't prioritize performance over correctness, they prioritize programmer control over compiler/runtime control.

replies(2): >>43536968 #>>43537845 #
hn-acct ◴[] No.43536968[source]
But they don’t really when some compilers silently remove code without mentioning it.
replies(1): >>43537170 #
Calavar ◴[] No.43537170[source]
The compiler removes code under the assumption that your code doesn't have UB. If your code has UB, that's a bug. "When my code is buggy the compiler outputs a buggy executable, but it's buggy in a different way than I want" has always struck me as somewhat of an odd complaint.

Of course it can be difficult to know when you've unintentionally hit UB, which leaves room for footguns. This is probably an unpopular opinion, but to me that's not an argument for rolling back UB-based optimizations; it's an argument for better diagnostics (are you *sure* you meant to do this), rigorous testing, and for eliminating some particularly tricky instances of UB in future revisions of the standard.

replies(2): >>43537387 #>>43539105 #
1. Maxatar ◴[] No.43539105[source]
>... has always struck me as somewhat of an odd complaint.

On the contrary I'd argue that the idea that any arbitrary bug can have any arbitrary consequence whatsoever is odd.

There's nothing odd about expecting that the extent of an operation is bounded in space and time, it's a position that has a great body of research backing it.