from anecdotal evidence, it seems like anything less than 0x10000 is always uninitialized memory. however, i'm sure this is not rigorously true. if not, can someone please point me in the right direction? i cannot seem to conjure up the correct search string to return any relevant hits.
thanks.
Uninitialized memory? Or inaccessable memory? (Does your program segfault?)
Are you obtaining your anecdotal evidence from a DOS terminal? (Was the program compiled with a true DOS compiler like DJGPP or Turbo C, or a Windows one line Dev-C++ or Microsoft Visual C++?)
I seem to recall someone posting something about how, in Windows, from 0 to a smallish value were unaddressable -- so that things like array[10] would still segfault, if array were NULL.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Well I don't need to search anywhere to kind of guide you in the right direction. Unless you have some prior knowledge about the system that is running your code, such generalizations will never hold true no matter what. Even with prior knowledge about the system you are running code on, you will only yield something platform specific.
Why are you trying to do this?
There is no such rule - yes, it's commonly some spare space around 0 [and I wrote a program that allocated 4K sections back towards 0 to see how far back I could get, and Win2K stopped at something like 192K, so 0x30000].
I will have a look to see if I can find it - but it would vary depending on the OS and perhaps also what the settings are in the OS.
And of course, just because you check that the address is ABOVE this address doesn't mean that it's valid - there is an almost infinite number of invalid addresses [that could be valid on another day, or in another run of the same application a few seconds later], so it's pretty pointless to try to catch some, when there are millions of other combinations available that AREN'T caught.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
i'm getting it from a combination of my debugger and from access violation error messages.Originally Posted by dwks
unitialized pointers that are members of variables always seem to have addresses less than 0x100, but i suppose that is actually better described as being address < sizeof(type)?
i would just like to have a means of validating whether there is something real on the other side of a pointer or not with out having to always set them equal to NULL if they aren't always initialized.
i should also note that luckily for me i have control over the hardware and OS my apps run on
Uninitialized variables just contain whatever happened to be in that memory location in the first place. If you run the same program multiple times in a row, it's possible that the same variable ends up getting put into the same place in memory.unitialized pointers that are members of variables always seem to have addresses less than 0x100, but i suppose that is actually better described as being address < sizeof(type)?
I can't really think of any other explanation of uninitialized pointers "always seem"ing to have values less than 0x100. Pointers are (probably) at least 4 bytes on your computer, so 0x100 is very low, really.
[edit]Oh, so you are actually asking this because you'd use the information?i should also note that luckily for me i have control over the hardware and OS my apps run on
Well then it would depend completely on your operating system. I think that 0 can even be a valid memory address, though NULL would have to be defined as something else. (I'm not too sure about that, though.)
1 could be a valid memory address, as far as I can see. [/edit]
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Lets not forget about the fact that virtual addressing exists too. Your program may call its memory one thing, however where it lies in actual RAM is an entirely different value.
I hate giving out complicated non-answers. But its all any of us can do for this one.
For some reason, I have the impression that this is an embedded system, or something small like that. If that is in fact the case, there might not actually be any virtual addressing. It's pretty unlikely, though.
Especially since my impression is probably wrong.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
If it is not a "standard OS", then we can't really know what (if any) addresses are valid. If you have MMU functionality [virtual memory addresses], then it's fairly easy [when you have access to the OS internals] to dig through the MMU tables to validate an address [and if you need to do it often, you could cache the address on a 4KB basis [or whatever the page-size is in that process].
If you haven't got MMU, then you would need to know what addresses are given out by the memory allocator, loader and other components.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
A much easier solution is to ALWAYS initialize your pointers to NULL and always set them back to NULL after you delete them. Then you don't have to worry about things that you can't control.
As far as I know, the only guarantee you have is that a NULL pointer is invalid; any other address could be valid.
it would be really nice if i could just set some default that would do that.
Well it's not that hard to do:it would be really nice if i could just set some default that would do that.
You can't expect the compiler to do everything for you.Code:char* pStr = NULL; int* pNum = NULL; ...
