0 is an address, but you can't reference it. What is at address 0? If address 0 holds something useful, how can a program access it?
Printable View
0 is an address, but you can't reference it. What is at address 0? If address 0 holds something useful, how can a program access it?
>What is at address 0?
Stuff you're not supposed to access. Duh.
The leprechaun lives there, if you can reference him he'll give you his pot of gold.
Code:#define NULL 0 //here be dragons
>#define NULL 0 //here be dragons
NULL isn't necessarily address 0. Neither is a null pointer.
Memory at location 0 is reserved by the operating system. Programs cannot access it. So you can't access it.Quote:
Originally Posted by Yasir_Malik
The fact you can address 0 (the so called null pointer) is simply a language implementation. It is not pointing to memory address 0. The C++ implementation uses this syntax instead to define a pointer that is pointing to nothing. And it was safe to do so by the language implementators exactly because memory address 0 cannot be accessed.
Bits, silly. :oQuote:
Originally Posted by Yasir_Malik
Depends. Old non-protected-mode OSs sometimes actually had stuff there. Like the interrupt table. Dereferencing NULL brought total havoc. It was used for fast checking, not for actual safety.Quote:
Originally Posted by Mario F.
Not necessarily. Modern OSs use virtual address spaces. Thus each address in your application can be mapped to something totally different in real memory. Address 0 is mapped nowhere - so there aren't any bits there.Quote:
Originally Posted by BMJ
I think I've seen this mentioned as one possible way. (Well, something like this -- it makes for good Googling.)Quote:
Originally Posted by Yasir_Malik
But on systems in which address 0 contains something interesting and useable, the usual NULL pointer issues may be dealt with in non-standard ways.Code:p == (type *)(0,0);
[edit]I think this is what I may have found a while ago.
[edit=2]Finally found old post.
AndQuote:
Originally Posted by Dave_Sinkula
Quote:
Originally Posted by Dave_Sinkula
Nerds.
The real-mode interrupt vector table starts at 0000:0000 and is always there regardless if the CPU is in protected mode or not.
And you can make a pointer to 0000:0000 but it won't do anything special. Address 0000:0000 is the low WORD of the first interrupt handler. You used to be able to manually patch into the IVT, but you are not allowed to in protected mode and this has nothing to do with Windows and everything to do with Intel.
I recommend looking at Randall Hyde's Art of Assembly book where he discusses the IVT and how to patch it VIA DOS int 21h and via your own code. Patching via your own methods was not advisable in the day due to the fact that, even though it would work, the OS had no knowledge of you patching into the interrupt chain which could cause issues later. The C functions that used to use DOS int 21h for the purpose of installing/uninstalling interrupt handlers was setvect() and getvect(). Of course these functions reside in dos.h and are only compatible with MS-DOS.
In a DOS session under XP, you are still allowed to patch the IVT either manually or through DOS int 21h.
I don't by any means have anywhere near the assembly programming experience that you do, but from my brief flirtations with various instruction sets I've found that although Intel is the chief market big guy, it's instruction set is built on a series of hopeless hacks and kludges just waiting to explode.Quote:
and everything to do with Intel.
Feel free to elaborate?! :)
I hate assembly. Reminds me of the time I tried to write an OS kernel. *shudders*
I think people who code in assembly are cool. It's the ones that actually like doing it that scare me.
i like assembly... but in my eyes c is a macro assembler *g* (c++ is maybe a bit too sophisticated for that view :) )
edit: well and with the intrinsics its easy writing assembler code that looks like c-code.