assigning pointer to NULL

[santosh]

But the effect can be detrimental on a system (which includes most
desktop environments) where the allocator can detect duplicate frees.

For that reason, I never set a freed pointer to NULL.

Same here on the basis that, in C at least, the programmer *must* always
be aware of which pointers have valid or invalid values at all points
in his program. Anything short of this is going to lead to bugs. From
this P.O.V. setting dangling pointers to NULL is redundant.

 

[Keith Thompson]

Not quite: you program will crash right there, when dereferencing the NULL
pointer, rather than at some other obscure and random place, so this helps
in detecting the bug.

Probably. There's no guarantee that an attempt to dereference a null
pointer will be detected at run time, (though it will be on most
systems).

 

[Flash Gordon]

santosh wrote, On 31/01/08 08:20:

Same here on the basis that, in C at least, the programmer *must* always
be aware of which pointers have valid or invalid values at all points
in his program. Anything short of this is going to lead to bugs. From
this P.O.V. setting dangling pointers to NULL is redundant.

In some situations setting pointers to NULL can be useful and used to
indicate whether it is valid or not. For example, I have some code of
this general form...

char *ptr = NULL;

/* do stuff */

if (cond1) {
ptr = malloc(something);
/* do stuff with ptr */
if (cond2) {
free(ptr);
ptr = NULL;
}
}
/* do stuff not using ptr */
if (cond3) {
/* do stuff using ptr */
free(ptr);
}


Note that the code deliberately has only one pointer to the malloc'd block.

 

[Richard Bos]

Not completely useless, only mostly.

If you know that the pointer you're setting to NULL was the only
pointer into that memory, then it's perfectly safe and useful.

It's only safe if you know that it's the only copy, but if you know
that, I don't see the use. You can just not use that one copy you know
about any more.

It's also not unreasonable to use the non-null-ness of a pointer as a
flag that you have useful information of some sort, and to want to
discard that information before you have something else to replace it
with.
(There are intelligent people who disagree with other intelligent
people about whether this indicates a design flaw.)

Once, when memory was as rare as the purifier aether and processors had
two registers a piece, it may have been useful. Now, with optimising
compilers and rarely no registers to spare, just use an extra int.

Richard

 

[Chris Dollin]

Not quite: you program will crash right there, when dereferencing the NULL
pointer,

Perhaps. It's not a requirement and I've used systems where it
didn't. It wouldn't surprise me if (some) embedded systems didn't
read-protect whatever-address-corresponds-to-the-value-of-the-null-pointer,
given that they have to shave margins everywhere. Could an embeddey
person comment?

 

[Morris Dovey]

Perhaps. It's not a requirement and I've used systems where it
didn't. It wouldn't surprise me if (some) embedded systems didn't
read-protect whatever-address-corresponds-to-the-value-of-the-null-pointer,
given that they have to shave margins everywhere. Could an embeddey
person comment?

None of the embedded stuff I've worked on (dating from 1970) ever
attempted to.

 

[Herbert Rosenau]

But the effect can be detrimental on a system (which includes most
desktop environments) where the allocator can detect duplicate frees.

For that reason, I never set a freed pointer to NULL.

Why not?

if (!ptr) ptr = make_object();

is the only choice you have to dedect an unset pointer, So

<type*> ptr = NULL; /* no object known yet */

.....

/* do something that will handle the object when it exists and ignore
it when not */

if (/* some condition that requires the object */) {
..... do something ....
}
.....
if (ptr) {
/* when we had a need to create the object do something with it */
}
.....
free(ptr);
ptr = NULL; /* we may come back to start later, so give the ptr a
clean state! again */


Without explicity clean up indeterminate pointers there is no chance
to avoid a crash by accessing it.

However a pointer ca be
- in use then it points to an existent object that can be
accessed
- is not in use then it is NULL, flagging that it is NOT in use

True, it makes no sense to set ptr to 0 when it goes thereafter out of
scope.

{
char *p = malloc(...);
if (!p) return return FAILED;
....
free p;
}
/* p does not exist anymore */
......


But

char *p = malloc(...);

/* do something with p */
free(p);
p = NULL; /* object pointed to by p is gone away */
......
if (!p) {
p = getit();
}
/* do something with p */
free(p);
return;
......

rules:

1. when a pointer is NULL then there is nothing assigned to,
so you can't use the pointer
2. When a pointer is NOT NULL then the object it points to exist
and you have access to it
3. free(NULL) is legal. So when your current scope knows of the
pointer and you has to give up the object it points to then
set the pointer to NULL after free() to flag that the pointer
is indeterminate now, because free() can't do that for you.
4. each malloc() needs a corresponding free()
or you'll end up with memory leaks
5. handle aliases carefully!

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[David Thompson]

"Roman Mashak" <[email protected]> wrote:

Legal, but useless. If you think you've found the royal road to memory
management, consider the following:

char *ptr, &ptr2;

Surely you meant * there; even in C++ (or lcc?) where the declaration
is legal the subsequent use below is not.

ptr=malloc(10);
ptr2=ptr+2;
free(ptr);
ptr=NULL;
if (ptr+2) crash_hard_and_without_grace();

Presumably you meant ptr2 there, as otherwise your example isn't
signficantly different from the OP's code. Even so, while a pointer
into free'd space is indeterminate and any use of it is technically
Undefined Behavior, there are very few if any systems where just
fetching such an invalid pointer actually crashes; indeed there are
very few where *derefencing* it causes an immediate crash, although
*storing through it* has a good chance of clobbering something that
has a reasonable chance of causing some failure, possibly noticed,
possibly not, often much later and far away in the program and thus
very difficult to debug, which is actually worse than a fast crash.

- formerly david.thompson1 || achar(64) || worldnet.att.net