GCC Undefined Behavior Sanitizer

[bearophile via Digitalmars-d]

Just found with Reddit. C seems one step ahead of D with this:

http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

Bye,
bearophile

[Paulo Pinto via Digitalmars-d]

Post by bearophile via Digitalmars-d
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
Bye,
bearophile

The sad thing about this tools is that they are all about fixing
the holes introduced by C into the wild.

So in the end when using C and C++, we need to have compiler +
static analyzer + sanitizers, in a real life example of "Worse is
Better", instead of fixing the languages.

At least, C++ is on the path of having less undefined behaviors,
as the work group clearly saw the benefits don't outweigh the
costs and is now the process of cleaning the standard in that
regard.

As an outsider, I think D would be better by having only defined
behaviors.

--
Paulo

[Marco Leise via Digitalmars-d]

Am Fri, 17 Oct 2014 08:38:11 +0000

Post by Paulo Pinto via Digitalmars-d

Post by bearophile via Digitalmars-d
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/
Bye,
bearophile

The sad thing about this tools is that they are all about fixing
the holes introduced by C into the wild.
So in the end when using C and C++, we need to have compiler +
static analyzer + sanitizers, in a real life example of "Worse is
Better", instead of fixing the languages.
At least, C++ is on the path of having less undefined behaviors,
as the work group clearly saw the benefits don't outweigh the
costs and is now the process of cleaning the standard in that
regard.
As an outsider, I think D would be better by having only defined
behaviors.
--
Paulo

I have a feeling back then the C designers weren't quite sure
how the language would work out on current and future
architectures, so they gave implementations some freedom here
and there. Now that C/C++ is the primary language for any
architecture, the table turned and the hardware designers
build chips that behave "as expected" in some cases that C/C++
left undefined. That in turn allows C/C++ to become more
restrictive. Or maybe I don't know what I'm talking about.

What behavior is undefined in D? I'm not kidding, I don't
really know of any list of undefined behaviors. The only thing
I remember is casting away immutable and modifying the content
is undefined behavior. Similar to C/C++ I think this is to
allow current and future compilers to perform as of yet
unknown optimizations on immutable data structures.

Once such optimizations become well known in 10 to 20 years or
so, D will define that behavior, too. Just like C/C++.

[via Digitalmars-d]

Post by Paulo Pinto via Digitalmars-d
As an outsider, I think D would be better by having only
defined behaviors.

Actually, this is the first thing I would change about D and make
it less dependent on x86. I think a system level language should
enable max optimization on basic types and rather inject
integrity tests for debugging/testing or support debug-exceptions
where available.

The second thing I would change is to make whole program analysis
mandatory so that you can deduce and constrain value ranges. I
don't believe the argument about separate compilation and
commercial needs (and even then augmented object code is a
distinct possibility). Even FFI is not a great argument, you
should be able to specify what can happen in a foreign function.

It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour. The correct
thing to do is to inject overflow checks in debug mode and let
overflow in results (that are accessed) be undefined. Otherwise
you end up giving the compiler a difficult job:

uint y=x+1;
if (x < y){
}

Should be optimized to:

{
}

In D (and C++) you would get:

if (x < ((x+1)&0xffffffff)){
}

As a result you are encouraged to use signed int everywhere in
C++, since unsigned ints use modulo-arithmetic. Unsigned ints in
C++ are only meant for bit-field stuff. And the C++ designers
admit that the C++ library is ill-specified because it uses
unsigned ints for integers that cannot be negative, while that is
now considered a bad practice


In D it is even worse since you are forced to use a fixed size
modulo even for int, so you cannot do 32 bit arithmetic in a 64
bit register without getting extra modulo operations.

So, "undefined behaviour" is not so bad, as long as you qualify
it. You could for instance say that overflow on ints leads to an
unknown value, but no other side effects. That was probably the
original intent for C, but compiler writers have taken it a step
further


D has locked itself to Pentium-style x86 behaviour. Unfortunately
it is very difficult to have everything be well-defined in a low
level programming language. It isn't even obvious that a byte
should be 8 bits, although the investments in creating UTF-8
resources on the Internet probably has locked us to it for the
next 100 years
 :)

[Iain Buclaw via Digitalmars-d]

On 16 October 2014 22:00, bearophile via Digitalmars-d

Post by bearophile via Digitalmars-d
http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

*cough* GDC *cough* :o)