On Wed, Mar 14, 2018 at 5:30 PM, Hyman Rosen <hyman.rosen_at_[hidden]> wrote:
> 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 allow
> optimizers to generate code by assuming that the behavior never occurs.

Infinite loops are a counter-example to this assertion.

~Aaron

>
>> 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.
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>