Fantastic exchange from DConf

[Patrick Schluter via Digitalmars-d]

On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
> On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
>> Walter: I believe memory safety will kill C.
>>
>
> Hi,
>
> I think that comparing languages like D to C is not 
> appropriate. C is a high level assembler and has different 
> design goals. A useful document to refer to is:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1250.pdf
>
> In particular: (although note the addition of facet f, which 
> echoes the sentiment that security is important)
>
> Keep the spirit of C. The Committee kept as a major goal to 
> preserve the traditional
> spirit of C. There are many facets of the spirit of C, but the 
> essence is a community
> sentiment of the underlying principles upon which the C 
> language is based. For the Cx1
> revision there is consensus to add a new facet f to the 
> original list of facets. The new
> spirit of C can be summarized in phrases like:
>
> (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. 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. 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.
But completely removing the code when one encounters for example: 
if(val+1 == INT_MIN) is simply nuts.