8

Possible Duplicate:
Setting variable to NULL after free …

I am learning about good C programming practices and my friend told me to always set the pointers to NULL after free()ing them (or calling a specific freeing function).

For example:

char* ptr = malloc(100);
...
free(ptr);
ptr = NULL;

or

struct graph* graph = create_graph();
...
destroy_graph(graph);
graph = NULL;

Why is this a good practice?

Update: After reading the answers, it seems an awful practice to me! I am hiding possible double-free() errors. How can this possibly be a good practice? I am shocked.

Thanks, Boda Cydo.

Community
  • 1
  • 1
bodacydo
  • 75,521
  • 93
  • 229
  • 319
  • @bodacydo Take a look at the "related" questions on the right of the page. –  Jul 29 '10 at 18:30
  • Thanks Neil and Michael. That question really answers my question. After reading the answers I have another question - doesn't setting pointer to NULL actually hide errors? Double free()'s no longer get detected! I am now confused as this is really hiding mistakes from showing up. – bodacydo Jul 29 '10 at 18:33
  • 1
    How so? Freeing a pointer and setting it to NULL allows the memory to be freed. If you then decide to free NULL, you should get an assert or some other warning. Double freeing memory is much harder to track than freeing NULL. – Michael Dorgan Jul 29 '10 at 18:35
  • But the double free in your program indicates you have written an incorrect program. Setting a pointer to NULL hides to problem and doesn't really solve it. – bodacydo Jul 29 '10 at 18:37
  • 3
    If you free NULL it silently does nothing, you don't get an assert. This is a Good Thing because it makes clean-up code easier, you need fewer ifs; but I can at least see where the OP is coming from on the "hides bugs" perspective. – zwol Jul 29 '10 at 18:39
  • 2
    @bodacydo: It hides double-frees, but not doing so can potentially hide wild pointer errors (accessing the pointer after the memory has been the freed). It's a trade-off, so it's not necessary bad (but not necessarily good). Personally I don't consider an extra free of a null pointer to necessarily be a bug, but accessing wild pointers is *always* wrong, so I side with assigning to `NULL`. – jamesdlin Jul 29 '10 at 18:45
  • 1
    I believe that the logic is that double free's are a smaller bug that actually using memory that has been freed. Assuming that you are on a machine where dereferencing NULL raises a signal you quickly find a critical bug. – Darron Jul 29 '10 at 18:46
  • I always assign dead pointers to NULL since their addressed memory is no longer valid. I quite like the idea of using a replace value which is set to NULL in release mode, but something like `(void*)0xdeadbeef` in debug mode so you could detect any errant usage. – Den-Jason Oct 02 '19 at 10:57

4 Answers4

14

While it can't hurt, it doesn't always help. The issue to consider is that it's easy for there to be multiple copies of the pointer and most likely you are only going to set a single one to NULL. The classic example of where it doesn't help at all is:

void free_graph(graph *g)
{
    ...
    free(g);
    g = NULL;  // not useful in this context
}

The problem here is that you are only setting the pointer that is local to free_graph to NULL and the pointer is held by the caller of free_graph will still have it's original value.

R Samuel Klatchko
  • 74,869
  • 16
  • 134
  • 187
6

This is considered a good practice by some because it prevents you from accidentally accessing the memory after it has been free()ed.

Darron
  • 21,309
  • 5
  • 49
  • 53
  • 1
    After reading the answers, I found it to be a bad practice - I am hiding errors of double-free! How can this possibly be a good practice? – bodacydo Jul 29 '10 at 18:32
  • 1
    Actually, it doesn't automatically prevent you from accessing it, but you can (and should) always check against NULL pointers, but you can't tell if a not-NULL pointer is valid. Therefore it is good practice. – cypheon Jul 29 '10 at 18:34
  • I am not yet convinced that it's a good practice. – bodacydo Jul 29 '10 at 18:38
2

Bad practice vote from me. If you do want to assign a value, set it to (void*)0xdeadbeef. Check what your CRT can do first though. A decent debug allocator will set freed memory to a pattern that's likely to cause a bomb when the pointer is used after it was freed. Albeit that it isn't guaranteed. But then not changing the pointer value is the better (and faster) solution.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
-5

I think yes ...

When you have finished using a portion of menory , we should free() it.This allows the memory freed to be used for some other purposes...like further malloc() calls.

Free takes a pointer to the memory as an argument and frees the memory to which the pointer refers to...

Hope this helps ... :)

Flash
  • 2,901
  • 5
  • 38
  • 55
  • 6
    -1: This doesn't answer the question. bodacydo was not asking, should he free memory. He was asking, should he set the pointers to NULL after freeing it. – Platinum Azure Jul 29 '10 at 18:32