Mill Computing, Inc. › Forums › The Mill › Architecture › NULL pointer
- AuthorPosts
- #3091 |
Hi Ivan
let’s say I have a null pointer in my application:
int * myPointer = NULL;
Would that be compiled to a local pointer or global pointer? If it was a local pointer, then NULL would not be 0, because it would have the local bit set.
I guess it would make sense to make NULL a special case and make it a global pointer? after all if you fork, a global NULL is still a global NULL, and having a value other than 0 for NULL would break a lot of applications.
- This topic was modified 7 years ago by goldbug.
It’s a global pointer. It has to be, because a local zero is an alias for the start of the turf’s private region.
The language does not in fact require a NULL to be binary zero – the “0” in “p = 0” is a token, not a value. Thus “p = (void*)(x-x)” is not guaranteed to leave p NULL. However, nearly all modern machines do in fact use binary zero for NULL, and we do too.
Are there any advantages to not having NULL work out to be 0? I can’t think of any off the top of my head, and you’d lose the advantage (at least on a Mill) of having uninitialized pointers automatically being NULL.
(As a hypothetical question, I mean… not as a direct response to Goldbug)
- This reply was modified 7 years ago by Dave.
The possibility is for legacy compatibility, for machines like the PDP-10 for which address zero had a hardware-defined meaning.Some future standard may deprecate it.
The Mill reserves more than the zero address, to catch code like:
struct S{int a; int b}; int* p = static_cast<struct S*>(NULL); ... //other code int i = *p;
Of course app code won’t have permissions for ultra-low addresses, but system code may, and hardware poisoning the range helps catch bugs in privileged code. In addition, it lets the fault distinguish between (likely) null-pointer vs. wild address.
We try to be friendly.
- AuthorPosts
You must be logged in to reply to this topic.