MSP430: what happened to the NULL pointer !?!

No expert on exact C or C++ spec or the MSP430. I thought a NULL pointer is just a pointer that points to address 0. From a HW perspective, address 0 is valid location. On a few processors, this is the reset vector or instruction. I believe application programs are linked in such a way as to avoid including 0 as part of it's memory space. A NULL address should not be valid withing the app program. A NULL pointer is then a convention for "nothing". All different for low level initialization code. On systems on MMUs, access to location 0 will cause an access violation. On the MSP430, I would guess accessing location 0 is perfectly okay. It's up to your code to test for a NULL pointer before doing so. The MSP430 gurus may say otherwise.

Norman Wong said:

No expert on exact C or C++ spec or the MSP430. I thought a NULL pointer is just a pointer that points to address 0. From a HW perspective, address 0 is valid location. On a few processors, this is the reset vector or instruction. I believe application programs are linked in such a way as to avoid including 0 as part of it's memory space. A NULL address should not be valid withing the app program. A NULL pointer is then a convention for "nothing". All different for low level initialization code. On systems on MMUs, access to location 0 will cause an access violation. On the MSP430, I would guess accessing location 0 is perfectly okay. It's up to your code to test for a NULL pointer before doing so. The MSP430 gurus may say otherwise.

Are you saying that you have no idea if the TI C/C++ compiler has an implementation for the null pointer?

No idea about the MSP430 compiler or it's NULL implementation. I don't think any C compiler implements NULL. It is usually just #defined to NULL. Usually in stdio.h. In C++, I think NULL is recognized as a typeless value of 0. It can be assigned to pointers or integers without complaint. You might have to elaborate on what exact problems you are encountering with the MSP430 compiler's handling of NULL pointers.

NULL can be tricky to understand.

The C standard basically says: "[the null pointer] is guaranteed to compare unequal to a pointer to any object or function."

The standard does not require that NULL be represented as all-bits-zero (see http://c-faq.com/null/machexamp.html), but it so happens that it is always all-bits-zero for all TI targets.

You are expected to not place a valid object at address zero, or at least not any object you need to access from C code.

However, if you absolutely must place something at address zero, you can go ahead and use a pointer to such an object; just be careful not to try to check to see whether it is the NULL pointer (see http://c-faq.com/null/accessloc0.html) .  Note that placing an object at address zero means your code is no longer strictly conforming C code.  You may need to declare the pointer volatile to prevent the optimizer from optimizing away code that dereferences it.

A question to Archaeologist.

Interesting reading. Looks like I've been a bit lax in test and assignment of NULL. My question is: How would I write code that does not assume NULL is zero? Suppose we use the test case of traversing through a linked list and adding a new node:

p = head;
while(p->next)
{
  p = p->next;
}
p->next = new_node;
new_node->next = NULL;

Would I need explicit comparision to NULL in the while condition? Can I use NULL or is there a reserved word for the real HW null?

It's the other way around.

Usually, since the 0h address is expected to contain nothing, one can use the 0 value to obtain the null pointer, and thus the NULL define. In this case the 0h is perfectly valid, and thus i wondered if the compiler provided a different implementation of the NULL value or a workaround of sorts.

The code I'm debugging requires a linked list. While debugging, the variable panel shows a plethora of nodes instead of cutting the list at the NULL pointer, thus i wondered if the problem lies in the debugger, in the compiler, in my code and, in case, which was the simplest way to solve the problem.

Since the manual doesn't state anything specific on the matter, and since i used the 0 value as i always do, that strange thing wasn't supposed to happen, so i asked the forum in case i missed something peculiar on this compiler. In the meanwhile i also checked the problem with a code snippet which seems to work fine, thus i suppose the "problem" lies in the debugger behavior.

Please read http://c-faq.com/null/index.html; it has a lot of discussion on this issue.

The short version is that you do not need to, and should not, take any special action on a system where NULL is something other than all-bits-zero.

The usual way to use a null pointer constant is to use the macro NULL.  You can also create a null pointer constant by converting the integer zero to a pointer type, even on systems where the null pointer constant is not all-bits-zero.

john doe95743 said:

i wondered if the compiler provided a different implementation of the NULL value or a workaround of sorts.

No.

Archaeologist said:

No.

Thanks.

I am guessing that the problem with NULL is not with the compiler as it is with the IDE, IAR or CCS. The IDE will dereference a pointer and display the contents of the referenced structure. Fior example, on Windows with MS Visual Studio will do this for non null pointer. It will not go through a null pointer. I am guessing that with the IDE for the MSP430, the IDE does go through a NULL pointer and display memory at address 0. Probably a bit of s surprise if you are expecting no display at all. Not sure that a small embedded system IDE should behave the same as a big OS IDE.