What happens if i try to write data to memory location where NULL POINTER is pointing, in ARM? _my understanding_ The Null Pointer is a Pointer pointing to 0. Does that mean memory location 0x0(the reset vector address, writing to this memory location is definitely not possible without IAP. so it may not be pointing 0x00 memory address)?
Or does it mean that the Pointer is pointing to nothing? If pointer is pointing to nothing, then where is the data being written in the following code if pQEI becomes a NULL POINTER?
void QEI_Init(uint8_t qeiId, QEI_CFG_Type *QEI_ConfigStruct) { LPC_QEI_TypeDef* pQei = QEI_GetPointer(qeiId); pQei->MAXPOS = 0x00; pQei->CMPOS0 = 0x00; //where is 0x00 being written if the pQEI becomes NULL POINTER . . . /* an so on*/ } LPC_QEI_TypeDef* QEI_GetPointer(uint8_t qeiId) { LPC_QEI_TypeDef* pQei = NULL; if(qeiId == 0) { pQei = LPC_QEI; } return pQei; }
Generates a HARD FAULT error. Was expecting (sometning like that should happen).
In 8051 0x0000 is a RAM address (Follows Harvard Architecture, so i am doubtful* that a NULL POINTER in 8051 will rewrite the 0x00 memory location). (*i have never tried it on 8051 either - never got a chance.)
But in Cortex M3, 0x00 memory location points to Flash, which cannot be written to without using IAP.
"In 8051 0x0000 is a RAM address "
No, it isn't that simple.
The 8051 have multiple address spaces. So NULL would just be offset 0 in whatever address space that is relevant for the code. If it is a pointer to code, then NULL would be start of flash. NULL for an XDATA pointer would be start of XDATA.
IIRC, I did have a case of NULL pointing to one of the variables with C51. Which must never happen, of course, with a standards-conforming compiler.
The 8051 have multiple address spaces was my point when i said Follows Harvard Architecture Thats why i wanted to know, where does NULL POINTER Point to? Does it Point to external RAM or Flash or Internal RAM. And because 8051 has multiple address space, a NULL POINTER may also point to (External or Internal) RAM area (which should never happen).
But i am not sure what happens for 8051. Hence asked for your experienced knowledge. 8051 doesnot even have MPU (so no Faults).
"Thats why i wanted to know, where does NULL POINTER Point to?"
As I said: That depends on the context, i.e. what type of pointer you have that you assign NULL to. It is the pointer type that decides what memory address space the pointer associates to. So it is the pointer type that decides if NULL will point somewhere in code or internal or external RAM.
Why do you say "which should never happen"? NULL pointers are regularly used. Just that NULL pointer indirection is almost always a big fail (with the exception of architecture-specific code that just happens to know there are memory that needs to be accessed at the same address as a NULL pointer will access - but such architecture-specific code should be avoided when possible).
When traversing data structures, it is very common that a pointer to the current (or maybe next) object is returned. And at end of traverse, a NULL pointer is returned to inform the loop that it should end the traversal.
And it is relevant to have NULL pointers to code space, in case the the source makes use of function pointers, to signal that a specific action doesn't have any function pointer registered.
And it is relevant to have NULL pointers to data space.
It is common - but not required that a NULL pointer happens to be offset 0 of the relevant address space. It depends on architecture and compiler - some architectures even have magic binary values that represents NULL. So any specific debate about binary values of NULL pointers or where they actually point has to be in relation to a specific architecture and/or compiler.
Since offset 0 is normally used, lots of compilers/startup files tries to place other information at offset 0, to make sure that the end-users variables will not happen to be stored at address 0, making &my_var happen to get the same binary value as a NULL pointer.
The purpose of a NULL pointer is not to cause a processor exception when it is dereferenced (although that is nice to have for debugging.) Its purpose is to serve as a special value for a pointer that could indicate a special condition in your program. You can compare a pointer with NULL to test for the special condition. The standard says that it 'is guaranteed to compare unequal to a pointer to any object or function'. It's OK if it points to internal RAM. In this case, the linker must ensure that no object in the program is located at this address. It is sufficient to reserve 1 byte at this address. Apparently, Keil failed to do that with C51.