macker
Holy Me-el
Registered: Nov 2000
Location: UK
Posts: 4736 |
quote: Originally posted by Smug Git
Pointers hold a number that represents a memory location, surely?
Yes.
quote: If that number (or whatever it is) doesn't correspond to a memory location that actually exists, then the pointer doesn't point to a memory location.
Who says the location doesn't exist? Internally the compiler will assign an arbitrary value(or more correctly "bit pattern") to represent a null pointer, which is 0x00000000 for most x86 compilers(I think. It's 0'ish). It will also ensure that no defined pointer will ever evaluate to that value(usually by treating the null as a kind of offset that all other pointer values will be offset by + 1). However, that address isn't necessarily explicity location 0x0(I can't be bothered to count 0's) in relation to the entire address space available on the PC. It might be location 0x0 in relation to the memory segment the pointer happens to be sitting in, 0x0 in the total malloc'd address space of the program, 0x0, 0x0 in the OS pagetable the program is currently sitting in, etc. In short, there is no explicitly set location of the null pointer 'cept that it's whatever the compiler decided to put it as, and subsequently how the OS/CPU/MMU decides to allocate the location of offset 0x0 for your piece of code.
And that's just for most common case x86 compilers. I think certain ancient incarnations of VAX use 0xc0000000 for nulls. Suddenly we get to repeat the whole of the previous paragraph for determinig where 0xc might point to. And it might be different on PowerPC, 6502, 68k, etc. In short, a null pointer's location cannot be defined.
And for extra spicy good funness you get processors like the Z8001 that actually has two bit patterns for NULL.
quote: As null pointers are promised not to be the same as any pointer that does point to a memory location, however they are internally represented, they aren't pointing to a memory location.
You got the first part right, the second part wrong. It merely states that a null pointer will always be different to a non-null pointer when used to evaluate a statement. The evaluation is actually done on the state of the pointer itself rather than the value of the pointer, when one of the pointers in the condition is null. In other words, the code internally just takes a shortcut.
quote: Picking on null pointers seems odd when stray pointers are more dangerous.
*shrugs* We're fairly insulated from the dangers of null pointers with high level code. It doesn't mean they've gone away and they're a common source of problems with sloppily written low level stuff like drivers or embeded applications where you might not have the privilege of an MMU(which in and of itself can provide certain protections against null pointers, but only so far as to make them fairly non-fatal to the health of your hardware).
__________________
Expecting people to be smart team players is like looking for double Ds in an oriental brothel.
Last edited by macker on 06-11-2005 at 02:29 AM
Report this post to a moderator |
IP: Logged
|