Pointers in c

[infobahn]

Apart from the dubious nature of this trick in general,

I disagree that it's either dubious or a trick.

> how does it help
the OP at all, who specifically asked about

It gives the best help I can think of that remains topical.

That is, how do you distinguish between a pointer to a simple,
non-allocated object, which is neither null nor invalid, and a random
integer cast to a pointer, which isn't null, but very likely _is_
invalid?

The only way I can think of that /might/ work would involve a huge
overhead; it involves building and maintaining a runtime "database"
of object representations that are known to be valid. This would
have such a horrendous runtime cost that I can't see anyone actually
choosing to do this.

There may, of course, be a platform-specific trick of which the
OP can take advantage, and personally I think that's what he is
after. Of course, such tricks are off-topic here.

 

[Steffen Fiksdal]

Yes, that would be a valid, (probably) undetectable way to corrupt your
library and very likely crash the program that has linked into it.


You can't. At least, you probably can't. And if you can, you won't find
out how on this newsgroup.


Why do you doubt them?

They don't give me the answer I would like to hear :-D

 

[Lawrence Kirby]

On Mon, 27 Dec 2004 06:12:27 +0000, infobahn wrote:

....

Quite so, but that doesn't mean it's impossible.

It depends how far you are prepared to go.

another_ptr = NULL;
/* now another_ptr is safely null too. */

In a lot of cases of this type, certainly the interesting ones where
doing this might provide a benefit, another_ptr is not accessible from the
code that called free(). So then you have to track in some way other
pointers that can point to the same object, transfer responsibility to
other parts of the program to clean up. You end up creating more
complication and opportunity for error than you resolve.

There are many cases where a null pointer is a valid value for a pointer
and indicates that the pointer doesn't point to anything. This is
especially true for pointers that are part of datastructures. If you
remove a leaf node from a tree you set the parent pointer to null to
restore the correct structure of the overall tree. It is also the case for
variables with static storage duration where the value of the variable can
be valid (at least testable) at any point in the program.

The issue is with freeing pointers whose value should not be used at
all after the free() operation, and it is a logic bug if they are. This is
more likely to be for simple automatic variables than datastructures or
variables with static duration. A good approach there is to ensure that
the variable goes out of scope soon after the free() operation. That is
typically the case anyway. Another example is freeing up a whole
datastructure where you don't need to set parent pointers to null because
the object holding them is itself about to be freed.

Destroying a pointer object is a more effective guard against invalid
access of its value than setting it to null.

Lawrence

 

[infobahn]

On Mon, 27 Dec 2004 06:12:27 +0000, infobahn wrote:

....




It depends how far you are prepared to go.




In a lot of cases of this type, certainly the interesting ones where
doing this might provide a benefit, another_ptr is not accessible from the
code that called free(). So then you have to track in some way other
pointers that can point to the same object, transfer responsibility to
other parts of the program to clean up. You end up creating more
complication and opportunity for error than you resolve.

This is certainly the case, and managing potentially dangling pointers
is, in my opinion at least, one of the most difficult parts of
robust programming.

The issue is with freeing pointers whose value should not be used at
all after the free() operation, and it is a logic bug if they are. This is
more likely to be for simple automatic variables than datastructures or
variables with static duration. A good approach there is to ensure that
the variable goes out of scope soon after the free() operation. That is
typically the case anyway. Another example is freeing up a whole
datastructure where you don't need to set parent pointers to null because
the object holding them is itself about to be freed.

Destroying a pointer object is a more effective guard against invalid
access of its value than setting it to null.

Certainly true, but not always practical - by which I mean the same
thing you do, i.e. that the code responsible for freeing an object
doesn't necessarily have control over the scope of a second pointer
to that object.

There is no single good solution to this, unless perhaps it's to take
up ballroom dancing instead of programming.