On 3/14/18, Hyman Rosen <hyman.rosen_at_[hidden]> wrote:
> On Mar 14, 2018, Lawrence Crowl <Lawrence_at_[hidden]> wrote:
>> Second, and most imporant, C's pointer and array model enabled
>> programmers to write in source code the kinds of optimizations that
>> compilers of the day were not doing. In particular, compilers were
>> not doing strength reduction in loops. In practice, a C program
>> could run in half the time of a Pascal program. Consequently, the
>> need for using assembler was lower, which avoided the significant
>> cost of writing in assembler. That optimization ability is exactly
>> why C became popular.
>
> Notice that this is an optimization *written by the programmer*.
>
> The most popular quote about C back in the day was "trust the
> programmer." The notion that parts of a program should be ignored
> because the compiler decides their behavior is undefined and therefore
> don't run is antithetical to that.

The phrase "trust the programmer" was directed to language designers
and compiler writers to not be nit-picking or straight-jacketing the
program. The long form of the phrase is "trust the programmer to
write correct programs". If the programmer writes incorrect programs,
it's on the programmer to deal with the consequences.

In fact, the modern compiler's behavior is entirely consistent with
that phrase. You are objecting to compilers trusting compilers to
write correct code.

>> The language has undefined behavior because it was targeted to systems
>> in which instruction sets did radically different things.
>
> But each of those systems did *something*. The compiler world generate
> the obvious (remember, transparency) instructions corresponding to the
> code, and the program would get whatever the result was.

Yes. And essentially programs were defined as correct when they were
effectively portable within that variation in systems.

> There was never a notion that undefined behavior gave the compiler
> permission to act as if the program never executed undefined behavior.

Oh, yes there was. Undefined behavior has meant "and your anchovy
pizza will arrive tomorrow" for decades. Partly the meaning is there
because once a pointer goes haywire, anything can happen.

> As usual, Ada was on top of this. Ada95 defined the concept of
> bounded error
> <http://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-p2-1.html#4>
> :
>
> *The general idea is that the behavior is not fully determined but
> neverthelessfalls within well-defined bounds.*

Ada did a number of good things to reduce the consequences of error.
It did so in large part because the DoD did not entirely trust its
programmers.

And BTW, the development and implementation of Ada costs way more than
most contemporary organizations could have spent. In particular, a
small research team at Bell Labs did not have that budget.

>> Compiler writers are often under intense pressure to squeeze more
>> performance out of programs. They have made legal code faster at
>> the expense of illegal programs. In doing so, they did not change
>> the language. On the surface, that is reasonable. The major
>> problem was that they started performing an entirely new class of
>> optimizations without warning anyone.
>
> The fundamental error is claiming that undefined behavior constitutes
> an "illegal program", or rather, that behavior which may not be
> definable in the same way in every environment should constitute an
> illegal program.

The compiler writers didn't make that claim. The standards committee
made that claim. Had C/C++ been developed 10 year later, the answer
may have been different, but that's all moot.

> It's my contention that the optimizationist sect of compiler writers
> are the people who pushed for making such unportable programs illegal
> to begin with.

Not so in my understanding and experience.

> I have no sympathy for people who press to get the wrong answer
> faster. It's the patricide asking for mercy as an orphan here.

The compiler writers have been working hard to deliver correct
answers faster. I cannot entirely blame them for making wrong
programs fail faster. I can blame them for not being sufficiently
cautious in exploiting the technology. That does not, however,
change the fact that the code has always been wrong.

-- 
Lawrence Crowl