Fantastic exchange from DConf

[Timon Gehr via Digitalmars-d]

On 14.05.2017 11:42, Patrick Schluter wrote:
>> ...
>> (a) Trust the programmer.
>> (b) Don't prevent the programmer from doing what needs to be done.
>> (c) Keep the language small and simple.
>> (d) Provide only one way to do an operation.
>> (e) Make it fast, even if it is not guaranteed to be portable.
>> (f) Make support for safety and security demonstrable.
>>
>> Proverb e needs a little explanation. The potential for efficient code
>> generation is one of the most important strengths of C. To help ensure
>> that no code explosion occurs for what appears to be a very simple
>> operation, many operations are defined to be how the target machine's
>> hardware does it rather than by a general abstract rule. An example of
>> this willingness to live with what the machine does can be seen in the
>> rules that govern the widening of char objects for use in expressions:
>> whether the values of char objects widen to signed or unsigned
>> quantities typically depends on which byte operation is more
>> efficient on the target machine.
>>
> If only the gcc and clang designers followed that rule.

It's precisely what they do. You are blaming the wrong people.

> These <beeep>
> consider that undefined behaviour allows to break the code in any way
> they fancy (the nasal demon thing). While pragmaticists interpret it as
> do the thing that is the simplest to implement on that hardware.

Those "pragmaticists" cannot be trusted, therefore they are not 
programmers. Why do they matter?

> The
> most ridiculous example being the undefined behaviour of signed integer
> overflow. Signed integer overflow is undefined in C because some obscure
> platforms may not use 2 complements for the representation of integers.
> So INT_MAX+1 does not necessarily result in INT_MIN.

It's _undefined_, not implementation-defined or unspecified.

Excerpt from the C standard:
> 3.4.1
> 1 implementation-defined behavior
>   unspecified behavior where each implementation documents how the choice is made
> ...
> 3.4.3
> 1 undefined behavior
>   behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
>   for which this International Standard imposes no requirements
> ...
> 3.4.4
> 1 unspecified behavior
> use of an unspecified value, or other behavior where this International Standard provides
> two or more possibilities and imposes no further requirements on which is chosen in any
> instance
> ...

What is it about "no requirements" that "pragmaticists" fail to 
understand? Not inventing artificial additional requirements is among 
the most pragmatic things to do.

> But completely removing the code when one encounters for example:
> if(val+1 == INT_MIN) is simply nuts.

Why? This is simple dead code elimination. The programmer clearly must 
have known that it is dead code and the compiler trusts the programmer.
The programmer would _never_ break that trust and make a program 
evaluate INT_MAX+1 !


The corollary to 'trust the programmer' is 'blame the programmer'. Don't 
use C if you want to blame the compiler.