

GCC Undefined Behavior Sanitizer – Ubsan - nkurz
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

======
nkurz
It seems like this is checking for undefined behavior in the binary that is
produced (accesses to undefined memory, division by zero), rather than
behavior that is "undefined" by the C standard (it's an signed int, which the
standard says is undefined on overflow, so I'll optimize by silently removing
your overflow check).

See here for more: [http://blog.llvm.org/2011/05/what-every-c-programmer-
should-...](http://blog.llvm.org/2011/05/what-every-c-programmer-should-
know_14.html)

At first I was excited, because I thought this sanitizer would help with these
cases, which I usually find much harder to debug than a division by zero or a
dereference of a NULL pointer that causes an actual crash. Am I wrong? Does
this sanitizer actually help with these cases? Is there anything else in the
pipeline that will?

------
userbinator
Some of what ubsan does sounds like the featureset of Valgrind; e.g. detecting
uninitialised variables and accesses outside of allocated memory, except it
can catch a few more bugs.

The fact that undefined behaviour is in practice a real pain has prompted some
work on C variants which replace most instances of UB with more reasonable
implementation-defined behaviour instead, e.g.
[http://blog.regehr.org/archives/1180](http://blog.regehr.org/archives/1180)
(discussed before here:
[https://news.ycombinator.com/item?id=8233484](https://news.ycombinator.com/item?id=8233484)
)

------
pjmlp
Given that we are going to stay with C and C++ for a while, this type of tools
should be part of the toolbox of any developer using the said languages and at
very least have a build with all knobs turned on.

~~~
3ifbyw
s/ a while/ever/

~~~
Animats
Not necessarily. Even the C++ committee now accepts that most of the C++ code
that will ever be written has already been written.

~~~
CJefferson
I have no idea where you get the claim from. I know many members of the C++
committee, and they expect new C++ to continue to be written, else why would
they bother with C++11/14/17?

~~~
Dylan16807
But do they expect _more_ new billions of lines of C++ to be written than have
ever been written before?

------
malkia
I've tried catching this little piece of undefined behaviour, but I was not
able to (gcc.4.9 -fsanitize=undefined)

    
    
      #include <stdio.h>
      int main() {
        return printf("a") + (printf("b") + printf("c"));
      }

~~~
cygx
What's undefined about that?

The order of evaluation is only unspecified, ie you can't know which
permutation of a,b,c you'll get - but you _will_ end up with one of them (as
long as IO doesn't fail)...

~~~
malkia
Thanks for cygx and readerrrr for correcting me. The difference (to me) of
undefined and unspecified is very subtle and often escapes my interpretation
when I have to use it later.

------
prudhvis
I am not familiar with undefined behaviour. Why exactly can't such behaviour
be caught during compile-time?

~~~
pcwalton
There are at least three ways I can see to answer your question, all of them
answering it in different ways:

1\. It's undecidable, because precisely detecting undefined behavior according
to the C and C++ standards in general reduces to the halting problem. It's
perfectly defined to have a program that dereferences a null pointer in a
branch that is never actually taken at runtime.

2\. The type systems of C and C++ were not designed to be
restrictive/expressive enough to disallow undefined behavior, for a multitude
of reasons (simplicity of implementation [especially in 1973], backwards
compatibility, concerns over performance).

3\. Defining away all undefined behavior via the runtime system (e.g. NaCl or
asm.js) requires a sophisticated runtime and incurs a performance penalty.

The first explains why C and C++ compilers cannot catch all undefined
behavior. The second explains why the C and C++ languages do not disallow
undefined behavior. The third explains why most C/C++-based systems do not
disallow undefined behavior at runtime.

------
tolyk
How does that compare to indefined behavior detection with Valgrind?

