Read on Twitter
In C, what does NULL look like, byte by byte in memory?
Okay, results are in!
Not much love for 0x55555555 huh?
Well first let's see what the C standard says.
Hm, so NULL's *value* must compare equal to 0. Case closed?
Not much love for 0x55555555 huh?
Well first let's see what the C standard says.
Hm, so NULL's *value* must compare equal to 0. Case closed?
No, not case closed. We're after the byte-by-byte layout in memory. That's called a representation.
So the value must compare equal to 0, but the representation is unspecified.
That means it's up to your implementation.
So the value must compare equal to 0, but the representation is unspecified.
That means it's up to your implementation.
What's an implementation? Usually a compiler.
But nothing says C must be compiled. C interpreters do exist!
Compilers are my jam though, so let's look at those.
But nothing says C must be compiled. C interpreters do exist!
Compilers are my jam though, so let's look at those.
We have a more precise question now:
How does a compiler decide on a representation for a null pointer?
Well that's usually determined by the ABI for your platform.
Sometimes an ABI is well defined, sometimes it's an ad-hoc mess adding on whatever happens to be there already.
How does a compiler decide on a representation for a null pointer?
Well that's usually determined by the ABI for your platform.
Sometimes an ABI is well defined, sometimes it's an ad-hoc mess adding on whatever happens to be there already.
Just like in web development har har
Okay so a non-zero null pointer representation is theoretically possible.
But does it happen in practice?
You bet! Stuff is codified in the standard because it actually happens.
Like 0xB00000000000 on the CDC Cyber 180 (great name), and 06000 on a Honeywell mainframe.
But does it happen in practice?
You bet! Stuff is codified in the standard because it actually happens.
Like 0xB00000000000 on the CDC Cyber 180 (great name), and 06000 on a Honeywell mainframe.
The clc FAQ also has an example of a machine where
sizeof (char *) > sizeof (int *):
http://c-faq.com/null/machexamp.html
That happens because it's a word addressed machine, and it takes literally extra lines on the bus to address something within a word. So it's a wider memory bus.
sizeof (char *) > sizeof (int *):
http://c-faq.com/null/machexamp.html
That happens because it's a word addressed machine, and it takes literally extra lines on the bus to address something within a word. So it's a wider memory bus.
But Kate, those are all stupid old machines. This doesn't apply to everybody's favourite and most secure CPU, x86. Right?
Well hey, you can totally violate an ABI if nobody catches you. I'm not the police.
Well hey, you can totally violate an ABI if nobody catches you. I'm not the police.
And that brings us to the TenDRA compiler, which can use 0x55555555 for its null pointer representation, if you like.
So here's an implementation of C compiling to x86 where the value of NULL is 0, but the underlying byte-by-byte representation is 0x55555555.
So here's an implementation of C compiling to x86 where the value of NULL is 0, but the underlying byte-by-byte representation is 0x55555555.
I forgot include assert(NULL == 0) in the above code, just to show that really is still true. So here you go, I added that too :)
Incidentally %p's output doesn't *need* to be hex. Its only requirement is that scanf can parse it back. I made one that output colour names once.
Incidentally %p's output doesn't *need* to be hex. Its only requirement is that scanf can parse it back. I made one that output colour names once.
