Undefined behaviours in D and C

[BCS]

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><