In article <11*********************@r29g2000hsg.googlegroups. com>
akappa <an******@gmail.comwrote:
>Mmh, hence if I do:
*((int*)0)
I'm referencing the NULL pointer and not the memory location at zero
address?
It sounds weird :)
Possibly. Perhaps they are the same thing (in fact, "usually" they
*are* the same), but possibly they are different.
Imagine, for a moment, that we create a language that looks exactly
the same as Standard C (C89 or C99, either one) except for one big
change. Instead of defining the "null pointer constant" the way C
does it, we add a new keyword, spelled nil, that produces "the null
pointer constant".
In C-- (or whatever this langauge is called), you do not write:
ptr = malloc(n * sizeof *ptr);
if (ptr == NULL) ...
but rather:
ptr = malloc(n * sizeof *ptr);
if (ptr == nil) ...
and if you want to "nil out" a pointer, you write, e.g.:
...
free(ptr);
ptr = nil;
Now, over here on the left, we happen to have a machine where memory
addresses 0x00000000 through 0xbfffffff are all valid, and any
address from 0xc0000000 through 0xffffffff is invalid. (This
machine can therefore use up to 3 GB of memory.)
If you would like your C-- compiler to be able to access all of
memory, you might want to make "nil" come out to 0xc0000000:
ptr = nil; /* compiles to "mov #0xc0000000,ptr" */
Here, *(int *)0 means "get me the bytes at address zero", while
*(int *)nil means "cause a fault because I attempt to dereference
a nil pointer".
Keeping all that in mind, let us "upgrade" from "C--" to regular C.
Now we have to write expressions such as:
ptr = 0; /* perhaps disgused as "ptr = NULL" */
to set "ptr" to the "nil pointer". But a C compiler can -- and in
the distant past, some did -- compile this to the equivalent of
"mov #0xc0000000,ptr". That is, the integer constant 0, used *as*
a pointer, compiles to the machine's most appropriate "nil pointer"
value, whatever that is.
So, C on this particular machine -- if we design the C compiler
so that it can access all memory -- really does attempt to access
location 0xc0000000 (not location 0) when you write:
*(int *)0
To access memory location zero, you simply use something that is
not an "integer constant zero":
int zero_but_not_integer_constant = 0;
int x;
x = *(int *)zero_but_not_integer_constant;
This gives you access to "memory location zero", on this machine,
with this clever C compiler that uses 0xc0000000 for the internal
representation of NULL.
(Again, such systems really did exist once. The original PR1ME
used a special segment for "null pointers", so that they were not
zero. As it turns out, it was so important to run badly-written
C code that *assumed* null pointers were all-zero-bits that they
modified the hardware, adding a whole new instruction -- TCNP, or
"test C null pointer" -- instead of continuing with this approach.
As a C programmer, you may choose whether to assume that future
systems will be forced to accomodate your bad C code, as PR1ME had
to, or whether to write *good* C code that will work even on "weird"
machines.)
(Note that if you are writing "inherently machine dependent code",
such as code to handle the bootstrap sequence on some particular
machine, it is probably pretty safe to make machine-dependent
assumptions. After all, the code that makes the Zorgblatt 15 boot
is probably not going to work at all on the Frobley 71, no matter
how portable you try to make it. There are cases where *some* of
the boot code can be shared, though -- so you might want to write
the "shareable" part in a portable way, and the machine-dependent
part in "whatever way works".)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
