Reply to thread

Message: [QUOTE="Dan Pop, post: 1714626"] But there is nothing preventing the implementor to use a null pointer representation that doesn't trap! Even if that representation is not all bits zero. Even then, why bother? If address registers exist in the first place, there *must* be a reason. Not using them for pointer operation is very likely to be inefficient, even if they have the same size as data registers for the simple reason that data registers get under greater pressure, while the address registers are unused. When the sizes are different, as in my example, the difference is going to be even more important. You make it sound as if there is any merit in having null pointers represented as all bits zero. Why would the implementor try to use that representation, if it's causing even the slightest inconvenience? The representation of null pointers is supposed to be the most convenient and efficient for the implementation, so there is no reason to consider all bits zero as an a priori solution, unless it is a convenient choice. Only an idiot would create an inefficient implementation for the sake of having null pointers represented as all bits zero. See below. Sheer nonsense. There is always an efficient solution: create a "reserved" object at some address and use its address as the null pointer representation. This is what most implementations are doing anyway, using the address 0 for this purpose. But there is nothing magic about this address, it just happens to be very convenient for this particular purpose, on most architectures. Since most modern machines treat addresses as unsigned integers, address 0 happens to be at the beginning of the address space and it's traditionally reserved anyway, on non-virtual memory architectures: it's the address of a GPR or an interrupt vector or the entry point in the boot loader (possibly ROM space). On virtual memory architectures, it's simply a matter of either leaving page zero unmapped (best choice, IMHO) or mapping but not using it (in read only mode, preferably). Dan [/QUOTE]

Verification