Hello Walter,
BCS wrote:
Currently the described code is legal, unsafe (it can result in
invalid pointers) and has undefined semantics (it can result in
unpredictable, implementation defined results). What I think
bearophile wants is for only the last to be changed, that is; you can
still do things that result in invalid pointers, but it does so in a
well defined way (at least with regards to the bit pattern the
pointer ends up as)
I don't think that's a useful thing to specify - where's the
advantage, and if D is on a machine that does pointers differently,
why make it impossible to port standard D to it?
#1 point to a machine in use now (keeping in mind D already dumped near/far
pointers) that "does pointers differently"?
#2 why allow code to compile, runs without error and work on one architecture
but on another, it compiles, runs without error and does NOT work?
I'll grant Michel's point about pointer->int for debugging, etc. but even
then I'd consider requiring an explicit cast.
In the end, while I see the point and see some merit, I'm almost natural
on the subject.
--
... <IXOYE><
