Undefined behaviours in D and C

bearophile bearophileHUGS at lycos.com
Sun Apr 18 14:46:11 PDT 2010


Walter Bright:

Sorry for the delay, I was away.
In this post I try to write in a quite explicit way.


>I don't see any way to make conversions between pointers and ints implementation defined,<

I see. Thank you for the explanation, I'm often ignorant enough.


In my original post I was talking about all places where C standard leaves things undefined. I'm not a C language lawyer, so I don't know all the things the C standard leaves undefined, but I know there are other undefined things in C beside the pointer <-> int conversion. That's why I was saying that it can be quite positive to write down a list of such things. So even if there is no hope to fix this pointer <-> int hole, maybe there are other C holes that can be fixed. I will not be able to write down a complete list, but I think having a complete list can be a good starting point.

In my original post I have listed two more things that I think the C standard leaves undefined:
- Pointer aliasing;
- Read of an enum field different from the last field written;

The first of them is fixed in C99 with the 'restrict' keyword. I guess the D compiler has to assume all pointers can be an alias to each other (but I don't remember if the D docs say this explicitely somewhere) because I think D prefers to not give keywords that the compiler itself can't then test and make sure they are correct.

The second of them is relative to code like:

enum SI { short s; int i; }
void main() {
  SI e;
  e.i = 1_000_000;
  int foo = e.s;
}
    
I think that according the C standard this code (the contents of foo) is undefined. Is D going to define this, or is it going to leave this undefined as in C? (Leaving it undefined can speed up a little the D code, but making it defined can make D more flexible, for example you can use an enum to split an int in two shorts in a reliable way). Note: here I am talking about D unsafe modules, because I think safe D modules can't use enums. So I am talking about the possibility of removing some undefined behaviours from unsafe D modules.

Probably the C standard leaves other things undefined. Some of them can cause bugs in unsafe D code.

Bye,
bearophile



More information about the Digitalmars-d mailing list