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