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
