On Dec 20, 11:44pm, Peter Seebach wrote:
} In message <20050731095833.GB24014@drowsy.duskware.de>, Martin Husemann writes:
} >On Sun, Jul 31, 2005 at 04:52:31AM -0500, Peter Seebach wrote:
} >> Well, strictly speaking, it causes undefined behavior on all platforms, it's
} >> just that on some platforms, the behavior is invariably "compare to the value
} >> that used to be there, which hasn't changed and has the same meaning it always
} >> did".
} 
} >I can't follow you. We are talking about comparing the pointer against NULL,
} >not about dereferencing the pointer and looking at the value it used to
} >point to, right?
} 
} Yes.
} 
} >The NULL value is magic enough so that this should work, segmented wiered arch
} >or not.
} 
} It's not the NULL part that's at issue; it's that some processors trap if you
} load an invalid address into an address register, and invalidate the addresses
} of freed memory.  So it generates a processor trap, and the question of what
} would happen if you got to the compare instruction is rendered irrelevant.

     One thing that occurred to me is that since a comparison is being
done, not a dereference, the value could be loaded into a data register
instead of an address register.  I will grant you that on some systems
an address might be longer then the data registers.  In this case, the
comparison would have to be done in parts.

}-- End of excerpt from Peter Seebach