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?
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.
My best code is written with the delete key.
The leprechaun lives there, if you can reference him he'll give you his pot of gold.
Code:#define NULL 0 //here be dragons
"Think not but that I know these things; or think
I know them not: not therefore am I short
Of knowing what I ought."
-John Milton, Paradise Regained (1671)
"Work hard and it might happen."
-XSquared
>#define NULL 0 //here be dragons
NULL isn't necessarily address 0. Neither is a null pointer.
My best code is written with the delete key.
Memory at location 0 is reserved by the operating system. Programs cannot access it. So you can't access it.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.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Bits, silly.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.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.Originally Posted by BMJ
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I think I've seen this mentioned as one possible way. (Well, something like this -- it makes for good Googling.)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.
AndOriginally Posted by Dave_SinkulaOriginally Posted by Dave_Sinkula
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Nerds.
Woop?
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.and everything to do with Intel.
Feel free to elaborate?!
I'm not immature, I'm refined in the opposite direction.
I hate assembly. Reminds me of the time I tried to write an OS kernel. *shudders*
M.Eng Computer Engineering CandidateB.Sc Computer Science
Robotics and graphics enthusiast.
I think people who code in assembly are cool. It's the ones that actually like doing it that scare me.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
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.
Last edited by Raven Arkadon; 07-14-2006 at 05:40 PM.
signature under construction