0xDEADBEEF?

but of course my programming conditions might not be everybody’s. I work
alone for one, and not on embeded systems (:
No… you misunderstand me!.. The INTENT is to FIND pointers that
weren’t set to NULL!

You can’t do this unless your environment supports this. There’s no
gauarantee that the memory that your program was given is fresh & clean or
was part of an old program that was running. FWIW, MSVC Sets memory errors
to 0xe5 (I think) by default when in debug mode, but 0s when not.

I agree that NULL should be used to indicate a pointer that is empty.
That is not what I’m saying. There is a difference between an EMPTY
pointer and an UNINITIALIZED pointer!.. An unititalized pointer can be
any value!!!

Sure, but it also can be a value that happens to be a valid pointer!

There is no way to say “if(!is_initialized(ptr)) {
initialize_ptr(&ptr);}”…

I think there’s an IsValidPtr() macro in MSVC if I’m not mistaken, but
it’ll only tell you if it’s within the program’s data/code range - not if
it points to valid data.

This is a tool to help find pointers that
should have been initialized (probably to NULL) but weren’t. If instead
you set all unitialized memory to 0x00, you can’t distingush between an
EMPTY and and UNITIALIZED pointer, so code that really is broken works
when it should insted fail.

I adapted a policy of making malloc/free wrapper functions that zero all
memory on allocation, and zero the pointer on a free operation, and in 6
years have never had this problem again. :wink:

–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me