Undefined behaviours in D and C

[bearophile]

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