Undefined behaviours in D and C

[Lars T. Kyllingstad]

bearophile wrote:
> 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;
> }


Don't you mean 'union' here, not 'enum'?

-Lars