On Wed, Mar 14, 2018 at 3:44 PM, Lawrence Crowl <Lawrence_at_[hidden]> wrote:
>
> 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.
>

No, that's wrong: <http://beza1e1.tuxen.de/articles/spirit_of_c.html>
It really is just "trust the programmer".

As far as incorrect programs, such programs were deliberately designated
as incorrect so that the optimizationists could break them. There is no
reason why a program that says int x; ... x = ~x + 1; should do
anything besides the obvious operations on ordinary 2's-complement
hardware, even when x is INT_MIN.

It is discouraging, looking at the linked C 2003 Rationale, how most of the
principles listed in the introduction are blithely violated by the C (and
C++)
standards, with absolutely no sense of irony or self-awareness:

   - Existing code is important, existing implementations are not.
   - C code can be non-portable.
   - Avoid “quiet changes.”
   - A standard is a treaty between implementor and programmer.
   - Trust the programmer.
   - Don’t prevent the programmer from doing what needs to be done.

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.
>

Then the error lies in characterizing certain behavior as undefined, when it
should instead be unspecified or implementation-dependent. Signed integer
arithmetic should mean "issue the underlying machine instructions and return
whatever result they provide." Even if some platforms trap on overflow,
that
does not mean other platforms should have license to assume that overflow
never happens in valid programs. Indirecting a pointer should mean "refer
to
the memory pointed to as if there is an object there of the pointer type"
and
should be undefined only if the pointer does not point to correctly aligned
memory owned by the (entire) program. And so on.


*No behavior should ever be designated undefined in order to
allowoptimizers to generate code by assuming that the behavior never
occurs.*

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.
>

What does that have to do with anything? Jean Ichbiah's design of Ada
was a work of genius, and it was done on paper. The free GNAT Ada
compiler, part of GCC, was developed along with the Ada95 standard
revision.

That does not, however, change the fact that the code has always been wrong.


You may believe that, but I believe you are wrong.