Undefined behaviours in D and C

[Lars T. Kyllingstad]

bearophile wrote:
> This recent blog post says nothing new for people that know C, it contains just few notes about some undefined C behaviours, but it's a starting point for what I want to say in this post:
> 
> http://james-iry.blogspot.com/2010/04/c-is-not-assembly.html
> 
> Undefined behaviours help adapt the language to different CPUs, but today PC CPUs are more similar to each other compared to the CPUs used when C was defined (because in an evolutionary tree most diversity is located near the root, in space or time); and Java/C# shows that with a very good JIT compiler you can have an efficient enough C-family language even if you remove many/most undefined behaviours from it (a JIT compiler can be better than a static compiler in this).
> 
> D semantics is quite based on C, but of course there are no written formal language specs yet, as you can find for C. Undefined behaviours are a really good source of bugs in programs (to avoid some of them you can try to put warnings in your compiler/lint for each undefined behaviour of your language).

Some time ago, I believe Walter decided to let @safe mean "no undefined 
behaviour".  Hopefully, this will reduce the number of 
undefined-behaviour related bugs.  After all, most D code should be 
marked @safe.

Here it is:
http://www.digitalmars.com/d/archives/digitalmars/D/Safety_undefined_behavior_safe_trusted_100138.html

-Lars