> but that the consequence of this should be somewhat bounded or as expected for the target machine.

Aren't "unpredictable results" and "no requirements" contrary to the idea that the behavior would be "somewhat bounded"?

▲

veltas 4 hours ago | parent [-]

Notice though "ignoring the situation" thru "documented manner characteristic of the environment". Even though truly you can read this in an uncharitable way, you could also try and understand the intent of this paragraph, and I think reading it for its intents is always the best way to interpret a language standard when the wording is ambiguous or soft, especially if you're writing a compiler.

I don't think you could sincerely argue that this definition intends to allow the compiler to totally rewrite your code because of one guaranteed UB detected on line 5, just that it would be good to print a diagnostic if it can be detected, and if not to do what's "characteristic of the environment". Does that make sense?

▲

gpderetta 4 hours ago | parent | next [-]

Ex falso quodlibet.

Bounding UB would be a nice idea, or at least prohibiting time-traveling UB (and there is an effort in that direction). But properly specifing it is actually hard.

▲

account42 an hour ago | parent [-]

Prohibiting "time-travelling" UB would be horrible as that's a very important mechanism for dead code elimination.

	▲	dzaima 13 minutes ago \| parent [-]
		Even if you forbid "time travel", you can still technically optimize many things as if time travel happened anyway - e.g. want to time-travel back to before some memory store? just pretend that the store happened, but then afterwards the previous value was stored back (and no other threads happen to see the intermediate value)! Only things you need to worry about then are things with actual observable side-effects - volatile, printf and similar - and C23 does note that all observable behavior should happen even if UB follows, and compilers can't generally optimize function calls anyway (e.g. on systems on which you can define custom printf callbacks, you could put an exit(0) in such, and thus make it incorrect to optimize out a printf ever).

▲

cracki 4 hours ago | parent | prev [-]

Reading for intent is pragmatic.

Reading adversarially is what people do who are looking for ways that something can be abused, from an offensive or defensive position.

Personally I am tired of the entire topic.

▲

veltas 3 hours ago | parent [-]

What's bad is when your compiler writers and most of the people involved in standardisation are reading it adversarially.

▲

account42 an hour ago | parent [-]

It's bad when compiler writers want to optimize correct code as much as possible, which is something their actual customers keep asking for?

	▲	veltas 5 minutes ago \| parent [-]
		When would optimizing correct code be harmed by not abusing UB (beyond its original intent, e.g. array access should be without overhead of checking for overflow)?