3

Possible Duplicates:
checking for NULL before calling free
What happens when you try to free() already freed memory in c?

Hope this isn't a totally dumb question. Anyway...

What happens when a null pointer is passed to free.

Thank you!

P.S. What about a standard compliant allocator? Thanks again!

Community
  • 1
  • 1
pic11
  • 14,267
  • 21
  • 83
  • 119

3 Answers3

13

It immediately returns without doing anything.

Per 7.20.3.2, paragraph 3:

The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 1
    I am so glad they changed the standard behavior to this. I remember when all calls to free where macros that wrapped the call to free in a test for NULL. – Martin York Jun 13 '11 at 03:35
  • The standard has always required `free` to behave this way. The ugly wrappers were either based on urban legend or a desire to support some broken nonstandard pseudo-C implementations. – R.. GitHub STOP HELPING ICE Jun 13 '11 at 05:06
  • Quite possibly true. But I am older than the standard. Since the first C standard was `N119` published on `18 Jun 90`. I first used C in 87 and their definitely was a problem free a NULL pointer in the version we were using. – Martin York Jun 13 '11 at 06:44
3

The man page says:

free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs. If ptr is NULL, no operation is performed.

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234
  • Keep in mind the man pages are non-normative, and often have POSIX specific extensions. They should not be relied upon as references for standard behavior. – Billy ONeal Jun 13 '11 at 02:57
  • Oh, dear. Is there a different set of documentation that is normative? – Jeremy Friesner Jun 18 '11 at 05:09
  • Man pages never were normative. For C and C++, the respective ISO/IEC standards are normative. For POSIX, the POSIX standard itself is normative. Man pages describe how your particular machine (might) work(s), but not how to achieve standard behavior across machines. (Man pages usually *do* have references to the actual normative standards where applicable near the end) – Billy ONeal Jun 18 '11 at 05:12
1

free(ptr) should do nothing if ptr is NULL.

In the real-world programming, this feature helps make your code even simpler like this:

class YourClass
{
public:

YourClass()
{
    m_ptr = (int*)malloc(sizeof(int));

    //Validate m_ptr and perform other initialization here
}

~YourClass()
{
    // You don't have to validate m_ptr like this
    // if (m_ptr)
    // {
    //     delete m_ptr;
    // }

    // Instead, just call free(m_ptr)
    // Notice: generally you should avoid managing the pointer by yourself,
    // i.e., RAII like smart pointers is a better option.
    free(m_ptr);
}

private:

int *m_ptr;
}
Eric Z
  • 14,327
  • 7
  • 45
  • 69
  • Might I suggest `auto_ptr` instead for this? – Billy ONeal Jun 13 '11 at 02:56
  • 2
    Don't write your own smart pointers. It is much harder than you think. This version of course fails because you have not followed the rule of three. But I went to a talk by Scott Meyers were he described his attempt at a smart pointer in one of his books. Even after multiple peer reviews when published he was getting e-mails about situations where it did not work perfectly. – Martin York Jun 13 '11 at 03:31
  • Yes, you should use smart pointer in most cases without reinventing the wheel. But when you have to do that yourself, that's a useful knowledge. I'll update my answer, thanks both. – Eric Z Jun 13 '11 at 05:12