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).

D already defines some behaviours that are left undefined in C, for example I 
think operations like 5%(-2) and 5/(-2) are defined in D, as well as shifts << 
>> when the number of bits shifted is larger than the number of bits of the 
value. And the removal from D of some other undefined C behaviours is planned 
in D, like the eval order of function arguments.

But I think some other undefined holes coming from C remain in D, for example 
regarding:
- Static casts between size_t/ptrdiff_t and pointers;
- Pointer aliasing;
- Read of an enum field different from the last field written;
- etc.

It can be positive to write down a complete list of such undefined C behaviours 
and decide if it's good to leave them undefined in D too, and where the answer 
is negative to define them. Here the C# language specs too can give some good 
suggestions.

D Bugzilla shows that there are few 'undefined behaviours' in some D constructs 
too, but starting from the C ones is good because there's already a lot of 
experience about using C to write programs.

Bye,
bearophile

Reply via email to