Theoretically I can say that
free(ptr);
free(ptr);
is a memory corruption since we are freeing the memory which has already been freed.
But what if
free(ptr);
ptr=NULL;
free(ptr);
As the OS will behave in an undefined manner I cannot get an actual theoretical analysis for this about what's happening. Whatever I am doing, is this memory corruption or not?
Is freeing a NULL pointer valid?
7.20.3.2 The
freefunctionSynopsis
#include <stdlib.h> void free(void *ptr);Description
The
freefunction causes the space pointed to byptrto be deallocated, that is, made available for further allocation. Ifptris a null pointer, no action occurs.
See ISO-IEC 9899.
That being said, when looking at different codebases in the wild, you'll notice people sometimes do:
if (ptr)
free(ptr);
This is because some C runtimes (I for sure remember it was the case on PalmOS) would crash when freeing a NULL pointer.
But nowadays, I believe it's safe to assume free(NULL) is a nop as per instructed by the standard.
free(ptr) where ptr is null has no side effects. But in any case, every memory allocated using malloc() or calloc() must be released afterwards using free() –
Carmelitacarmelite free(NULL) by testing the pointer against NULL before calling free() –
Carmelitacarmelite All standards compliant versions of the C library treat free(NULL) as a no-op.
That said, at one time there were some versions of free that would crash on free(NULL) which is why you may see some defensive programming techniques recommend:
if (ptr != NULL)
free(ptr);
NULL ptr and treat it like a nop. Drepper personally opposes the safer string functions so glibc will likely never be compliant. –
Jalbert If ptr is NULL, no operation is performed.
says the documentation.
I remember working on PalmOS where free(NULL) crashed.
NULL was one of the big running differences of the Palm toolbox compared to the standard library. –
Drawing free (MemPtrFree) was not standards compliant, and free was aliased to MemPtrFree as a (crude) attempt to provide a standard-like API. –
Karyotin free(ptr);
ptr=NULL;
free(ptr);/*This is perfectly safe */
You can safely delete a NULL pointer. No operation will be performed in that case.In other words free() does nothing on a NULL pointer.
Recomended usage:
free(ptr);
ptr = NULL;
See:
man free
The free() function deallocates the memory allocation pointed to by ptr.
If ptr is a NULL pointer, no operation is performed.
When you set the pointer to NULL after free() you can call free() on it again and no operation will be performed.
free(NULL) is perfectly legal in C as well as delete (void *)0 and delete[] (void *)0 are legal in C++.
BTW, freeing memory twice usually causes some kind of runtime error, so it does not corrupt anything.
delete 0 is not legal in C++. delete explicitly requires an expression of pointer type. It is legal to apply delete to a typed null-pointer value, but not to 0 (and not to NULL). –
Township void* either :P Which destructors(s) should it run? –
Myron void * as long as it is a null-pointer. –
Township buf1=malloc(X); free(buf1);buf2=malloc(X);free(buf1); - here if you're unlucky, buf2 got the exact same address as buf1, and you accidentally freed buf1 twice, so on the 2nd free of buf1 you actually freed buf2 silently, without casuing any (immidate) error/crash/whatever. (but you'll still probably get a crash next time you try to use buf2 - and this scenario is very unlikely if you're running on ASLR) –
Watchful free(ptr) is save in C if ptr is NULL, however, what most people don't know is that NULL need not be equal to 0. I have a nice old-school example: On the C64, on address 0, there is an IO-Port. If you wrote a program in C accessing this port, you'd need a pointer whose value is 0. The corresponding C library would have to distinguish between 0 and NULL then.
Kind regards.
not memory corruption, but behavior depends on implementation. By standard, it should be a legal code.
Although it is safe nowadays, I always use the following macro to free pointers:
#define FREE(ptr) \
{ \
if ((ptr) != NULL) \
{ \
free(ptr); \
(ptr) = NULL; \
} \
}
ptr is pointing to some memory location, lets say 0x100.
When you free(ptr), basically you are allowing 0x100 to be used by memory manager to be used for other activity or process and in simple words it is deallocation of resources.
When you do ptr=NULL, you are making ptr point to new location(lets not worry about what NULL is). Doing this you lost track of the 0x100 memory data.This is what is memory leak.
So it is not advisable to use ptr=NULL on a valid ptr.
Instead you could do some safe check by using :
if(ptr != NULL) {free(ptr);}
When you free(ptr) where ptr is already pointing to NULL, it performs no operation.So, its safe to do so.
NULL so if it is freed again there will not be a double free error –
Arteriole free(ptr); ptr=NULL; is extremely different from ptr=NULL; free(ptr); The first deallocates the memory (variable gets its read/write rights to that chunk of memory revoked) and then removes any way of accessing that memory, which is completely safe and fine (as long as you never assign anything to ptr without also allocating new memory to ptr in the future). The second removes any way of accessing that memory (ptr=NULL;), then tries to access it in order to revoke its rights (via free(ptr))! –
Haynor © 2022 - 2024 — McMap. All rights reserved.
delete NULLis not valid in C++. delete can be applied to null-pointer values of concrete type, but not toNULL.delete (int*) NULLis legal, but notdelete NULL. – Townshipptrpoints to memory, and you don't callfreeon it, then the memory will leak. Setting it toNULLjust loses your handle on the memory, and leaks. If theptrhappens to beNULL, callingfreeis a no-operations. – Myronfree(ptr)withptr = NULL. No one said anything like that. – Townshipfree( someIntPointer )===> tellOperatingSystemThat_someIntPointer_noLongerHasRightsToReadNorWrite_sizeOfInteger_AmountOfMemory.ptr = NULL;means that the pointer is pointing to memory address 0x00000000 (there may be more hex 0s added to the end of that number, but it still has memory address 0). This statement is NOT saying what data lies at that address, nor how many bytes will be stored there (since no type) – Haynor