Reply to thread

Message: [QUOTE="Jens.Toerring, post: 2384070"] I think it's not so much "compiler magic" but a question how the underlying hardware works. Let's assume you have a machine that has dedicated address registers (like e.g. the 68000 processors had). Moreover, the OS is allowed to unmap the address from the virual address space of a process once free() has called on a pointer. If now the processor also tests if an address it loads into an address register is mapped into the address space of the process (with an exception for an address that represents the NULL pointer) and e.g. segfaults when it isn't than you have a sitation where none of the bits of the pointer ever changed but taking its value (by loading it into an address register) isn't possible. If memcpy()ing the content of that pointer somehwere else is possible may depend on such a machine on what kind of machine instructions are used in the process - if the value of the pointer gets copied into an address register in the process it would crash the program, if it's going in a data register (or no register at all) it might work perfectly well. While no machine is required to work that way it's possible to write a conforming C compiler such a kind of machine. But therefore you need some allowance in the standard that says that "the result taking the value of a free()ed pointer is indeterminate". Also a lot of other seemingly hard to explain requirements (like, for example, why, when you have an array a[10], calculating a+20 is undefined) suddenly make a lot of sense on such a machine. Regards, Jens [/QUOTE]

Verification