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
