corrupted pointer ????

[sparsh610]

hello friends,
i have read a question about pointers and seems totally new concept for me ..
how would you find out if one of the pointers in a linked list is corrupted or not?
pointer is corrupted ??,, don't understand :(
pls help
your friend : sparsh

[asrockw7]

A 'corrupted pointer' could be a pointer that points to already free'd data (when using dynamic allocation via malloc/calloc), or maybe just something that contains an address that you don't intend for it to contain.

That being said, you don't just 'find out' whether or not a pointer is a bad pointer because what a pointer holds is only an address and it is an address that can be of any context so to determine if a pointer is bad depends on what you consider bad. A tell-tale sign is usually a program crash or just outright runtime errors, though.

I'm not saying you cannot find out if a pointer is bad, I'm saying it's not as easy as determining whether 'x == NULL'.

You can try to debug a linked list by printing the values/addresses of each node/step and check if those are what you expect.

[mike_2000_17]

When it comes to corrupt pointers (as in, pointer that hold a non-NULL address, but the address points no-where (a freed memory, or otherwise)), there really isn't any mechanism to find out about it after the fact, except via a crash or other weird behaviors.

The name of the game here is prevention. You have to be disciplined and vigilant to make sure that you keep your pointers consistent.

Otherwise, if you do have problems for which you suspect that you have pointer problems, there are external tools you can use to find the problem(s). In particular, a good debugger should allow you to track pointer addresses as you step through the code, so, you can manually inspect those pointer values. Then, there are memory profiling tools, like Valgrind (under Unix-like environments) which is really good for that, I'm sure VC++ has nice tools too. A memory tool like that should detect "dangling" pointers (pointers that refer to memory that was freed), memory leaks (when you no longer have any pointer pointing to some memory that was not yet freed, which means you can never free it), and it will be much stricter about memory accesses and be able to trace the offending code (illegal access) back to the line of code that it originated from. This is makes the process of finding such errors much easier.

But again, the best remedy is prevention. Once you develop good discipline and techniques to deal with dynamic memory and pointers, those problems just never occur anymore (e.g., I haven't really used a memory debugger in many years, that's why I don't even know how well VC++ does it, I just never use these tools anymore, except for the occasional Valgrind runs that tell me I have 0 memory issues).