i was running a small c program:
#include<stdio.h>
int main()
{
char *p;
p = (char *)malloc(10);
free(p);
free(p);
free(p);
printf("\npointer is freed!!\n");
}
basically i am freeing the memory which has already been freed. i think should result in a core dump!!is it not so?
but it is printing the
pointer is freed!!
am i wrong some where?
I would expect DEBUG builds of most compilers to be able to detect this type of a failure and report exactly what happened. So would MSVC do.
In RELEASE, it could be optimized to generate unpredictable behavior faster.
It depend on the implementation of your OS (linux, windows...) who implement this function. Their behaviors may be different depending on the OS (undefined behavior), so you must not rely on them and you must free only one time all allocated memory in you program.
EDIT: it is not part of the OS but of the standard library which differ depending on the OS.
Just to add to the other answers, I'd like to note that if you set the pointer to NULL and then called free(), the behaviour wouldn't be undefined anymore. It's pretty much a no-op. However, if the pointer is freed and you call free() on it again before assigning the pointer to a different location (even NULL), you can't be sure of what happens. It could result in a core dump on some implementations and nothing would happen on some others.
As per the man page, "if free(ptr) has already been called before, undefined behavior occurs."
It doesn't need to blow up; "not doing anything" is perfectly acceptable undefined behaviour. Also are nasal demons. Don't rely on it.
There are multiple issues with your program:
malloc()
andfree()
, you should do#include <stdlib.h>
before calling any of those functions.malloc()
: it returns avoid *
, which can be assigned to any other pointer type safely (except function pointers). So, you can do:p = malloc(10);
malloc()
orrealloc()
, using the pointer value in any way is bad: in particular, you cannot callfree()
on it again.int main()
is better written asint main(void)
.main()
returnsint
, you should return a value from it. Traditionally, 0 means success.Of course, the main (no pun intended) problem with your program is freeing it many times, but other issues mentioned above are important too. Once you've
free()
'd a pointer successfully, callingfree()
on it is undefined behavior: the program can do anything, including (unfortunately), seeming to not do anything bad. I say "unfortunately" because it might give you a sense of security that it's okay tofree()
a pointer more than once.freeing already freed memory, leads to undefined behavior, you got lucky, in this case, on other times you might get your core-dump