Live data from Hacker News

Undefined Behavior in 2017

blog.regehr.org

11–20 of 120 posts

Re: Undefined Behavior in 2017

#11

Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.

Because of benchmarks fights.

UB is the result of C compiler vendors not wanting to give up on their precious optimizations or hardware configurations back when ANSI C was initially being done.

They could have done like in other languages and have ANSI C without UB, but then they would need to give up on some hardware features or lose in one or other benchmark.

Re: Undefined Behavior in 2017

#12
I wish there was a GCC switch that made the optimizer go "This is clearly undefined behaviour. I'll stop this compile right here", as opposed to "This is clearly undefined behaviour. Sweet jackpot, it means I can do whatever the heck I want. Drop those NULL checks below, I've got the golden UDB ticket now"

Re: Undefined Behavior in 2017

#13

Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.

Because a lot of UB cannot be efficiently determined at compile time. Hence, UBSan.

Re: Undefined Behavior in 2017

#14
post #2

How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?

They didn't even existed in stone age low-level languages like ESPOL, NEWP, PL/8, PL/S, Mesa, Modula-2.

And I am only mentioning the most known ones during the 10 years before C was born until early 80's.

Sure some of them also had safety issues like use-after-free, but not in the same amount as C.

Re: Undefined Behavior in 2017

#15

Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.

They are called undefined behaviors because the compiler developers are free to do whatever they want when they come across a code that instigates an undefined behavior.

Mostly new compilers now a days do handle such behavior with a compiler error or warning. So if you try to do an out of bound shift a new compiler might throw a warning, but according to the C standard it does not have to. In fact instead of throwing a warning it can wipe your complete hardware and that too is allowed according to the C standard...

In contrast there is implementation defined behavior, and unspecified behavior. Where the compiler developers have to document and take care of certain things.

I wrote a detailed article about the subtle difference you can check that out....

https://medium.com/@faizan10114/understanding-c-terminologie...

Re: Undefined Behavior in 2017

#16
post #12

I wish there was a GCC switch that made the optimizer go "This is clearly undefined behaviour. I'll stop this compile right here", as opposed to "This is clearly undefined behaviour. Sweet jackpot, it means I can do whatever the heck I want. Drop those NULL checks below, I've got the golden UDB ticket now"

The optimizer doesn't work that way. It assumes the code does not do UB and then removes branches that can never be taken if the code executes no UB.

That's different from "This is UB, and now I do ...".

Re: Undefined Behavior in 2017

#17
post #13

Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.

Because a lot of UB cannot be efficiently determined at compile time. Hence, UBSan.

It is very easy to be efficiently determined at compile time, other systems programming languages do it, by not having UB on their language standard to start with.

If people prefer "performance trumps correctness" and "winning compiler benchmarks is what counts" then they should happily keep getting exploited.

Re: Undefined Behavior in 2017

#18
post #15

Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.

They are called undefined behaviors because the compiler developers are free to do whatever they want when they come across a code that instigates an undefined behavior. Mostly new compilers now a days do handle such behavior with a compiler error or warning. So if you try to do an out of bound shift a new compiler might throw a warning, but according to the C standard it does not have to. In fact instead of throwing…

> So if you try to do an out of bound shift a new compiler might throw a warning, but according to the C standard it does not have to.

Right, for doing so needs to determine that this is happening, which neither GCC and Clang can do for fairly trivial cases like

    for (i = 0; i 

Re: Undefined Behavior in 2017

#19
post #17
post #13

Earlier quoted context omitted.

Because a lot of UB cannot be efficiently determined at compile time. Hence, UBSan.

It is very easy to be efficiently determined at compile time, other systems programming languages do it, by not having UB on their language standard to start with. If people prefer "performance trumps correctness" and "winning compiler benchmarks is what counts" then they should happily keep getting exploited.

I do see your point, but that'd be a different language. With the standardised C we have, it's not easy.

Re: Undefined Behavior in 2017

#20
I wonder why he mentions this TIS interpreter but not the development of complete semantics for C and specifically the k framework (https://github.com/kframework/c-semantics).

Afaik, kcc is also really good at finding undefined behavior. Regehr even wrote about it in the past (https://blog.regehr.org/archives/523).

Post reply on HN