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.
