[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MIT discovered issue with gcc



* Octavio Alvarez <alvarezp@alvarezp.ods.org> [131127 21:28]:
> On 26/11/13 11:37, Mark Haase wrote:
> >Compiler developers, for better or worse, reserve the right to do
> >whatever they want with undefined behavior, and it's up to the person
> >writing the C code to not include undefined behavior in their own program.
>
> That's a fallacy. The fact that a compiler does not violate the
> standard does not imply it is behaving sane. Thus, not violating the
> standard does not imply not having a bug.

"Not violating the standard means no bug" would indeed be a fallacy.
But that is a different statement that what you replied to.

> Considering a programmer would not ever *ever* want to fall into
> undefined behavior, the compiler should just issue warnings before
> making any kind of assumptions based after undefined behavior. Those
> warnings could be silenced with flags. This is a way of "yes, I'm
> sure of what I'm doing".

The whole point of undefined behaviour is this type of warnings are not
possible. And if such warnings would be possible, that kind of code
would better produce an error than making that behaviour undefined.

Undefined behaviour is especially reserved for anything where the
compiler can on all forseeable platforms, produce fast code in the
usual case, but strange things can happen in the undefined case.

Let's take the example of signed overflow:

Almost every operation with numbers has some chance for overflow,
depending on the numbers. While for unsigned numbers the result
is quite easy to define (just calculate and go module 2^wordsize)
and processors come with instructions doing that efficiently
(or it is easy and fast to emulate them). But with signed numbers,
just defining some specific behaviour means severly limiting the
compiler what processor instructions to use. It might even mean
that a compiler would have to generate a conditional for every
operation with signed numbers to just test first if it would
overflow. So this little trick of making the behaviour undefined
can speed up the programs a compiler generates a significant
amount of time.

So allowing some operations that are valid or invalid depending
on what input it is given is already needed if you want fast
programs.

Next the compiler has to decide what to do with things like

void foo(int s, int e) {
        int i;
        for (i = s ; i != e ; i++) {
                something();
        }
}

Given that writing programs that have signed integers overflow
is already forbidden (by making them undefined), the compiler
can translate this to:

DO e-s TIMES
        CALL something

Without using the information about undefined behaviour, it would
have to translate it to:

IF s < e
        DO e-s TIMES
                CALL something
ELSE
        DO range(int)-(s-e) TIMES
                CALL something

or if e was a long:

IF s < e
        DO e-s TIMES
                CALL something
ELSE IF e <= MAXINT
        DO range(int)-(s-e) TIMES
                CALL something
ELSE
        ENDLESS LOOP
                CALL something

As people want fast programs it makes sense in my eyes to say here:
This modification has big advantages and only is a problem for programs
already not supposed to work by the standard.

	Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


Reply to: