Malloc/Free - freeing memory allocated by malloc

[Spriggan]

if you make dynamic alloc memory,
you must dealloc memory.
if you don't dealloc memory, your system will be nockdown.
OS is probably dealloc memory in your application if it is automatic
variables at application terminated.
but dynamic alloc memory is not dealloc by OS at application teminated. why?
that is not Automatic Variable. Indicate it, Dangling Pointer.
that is, only your resposiblity.

otherwise, reference by this code.

int *data = (int*)malloc ( sizeof(int) * 100 );
..
..
..
free(data);
data = NULL;

is correct.
( reference by MSDN )

if you want to use easy, make macros.
ex) #define SAFE_DELETE(p) if(p) { free(p);
(p)=NULL; }

if you run function "free()", pointer is must be NULL. that is more cleary.

 

[Spriggan]

if you make dynamic alloc memory,
you must dealloc memory.
if you don't dealloc memory, your system will be nockdown.
OS is probably dealloc memory in your application if it is automatic
variables at application terminated.
but dynamic alloc memory is not dealloc by OS at application teminated. why?
that is not Automatic Variable. Indicate it, Dangling Pointer.
that is, only your resposiblity.

otherwise, reference by this code.

int *data = (int*)malloc ( sizeof(int) * 100 );
..
..
..
free(data);
data = NULL;

is correct.
( reference by MSDN )

if you want to use easy, make macros.
ex) #define SAFE_DELETE(p) if(p) { free(p);
(p)=NULL; }

if you run function "free()", pointer is must be NULL. that is more cleary.

 

[Spriggan]

if you make dynamic alloc memory,
you must dealloc memory.
if you don't dealloc memory, your system will be nockdown.
OS is probably dealloc memory in your application if it is automatic
variables at application terminated.
but dynamic alloc memory is not dealloc by OS at application teminated. why?
that is not Automatic Variable. Indicate it, Dangling Pointer.
that is, only your resposiblity.

otherwise, reference by this code.

int *data = (int*)malloc ( sizeof(int) * 100 );
..
..
..
free(data);
data = NULL;

is correct.
( reference by MSDN )

if you want to use easy, make macros.
ex) #define SAFE_DELETE(p) if(p) { free(p);
(p)=NULL; }

if you run function "free()", pointer is must be NULL. that is more cleary.

 

[Spriggan]

if you make dynamic alloc memory,
you must dealloc memory.
if you don't dealloc memory, your system will be nockdown.
OS is probably dealloc memory in your application if it is automatic
variables at application terminated.
but dynamic alloc memory is not dealloc by OS at application teminated. why?
that is not Automatic Variable. Indicate it, Dangling Pointer.
that is, only your resposiblity.

otherwise, reference by this code.

int *data = (int*)malloc ( sizeof(int) * 100 );
..
..
..
free(data);
data = NULL;

is correct.
( reference by MSDN )

if you want to use easy, make macros.
ex) #define SAFE_DELETE(p) if(p) { free(p);
(p)=NULL; }

if you run function "free()", pointer is must be NULL. that is more cleary.

 

[William Ahern]

if you want to use easy, make macros.
ex) #define SAFE_DELETE(p) if(p) { free(p);
(p)=NULL; }

if you run function "free()", pointer is must be NULL. that is more cleary.

I usually just do the following, which I find clearer:

free(p), p = NULL;

The `if (p)' is not necessary:

free(NULL); /* Okay */

 

[Richard Bos]

if you make dynamic alloc memory, you must dealloc memory.
if you don't dealloc memory, your system will be nockdown.

If by "nockdown" you mean that it will crash... not necessarily. You may
leak memory, but that will not necessarily bring down the system. Leak
enough memory for long enough, yes, you'll cause problems; but leak a
small amount of memory once and then terminate, and you'll probably
notice nothing amiss. The real problem is that such problems tend to
accumulate; memory requirements get bigger, and with them, the part of
it which is leaked.

but dynamic alloc memory is not dealloc by OS at application teminated. why?

Says who? On most OSes it is, and I'd call any modern OS on which it
isn't broken.

that is not Automatic Variable. Indicate it, Dangling Pointer.
that is, only your resposiblity.

otherwise, reference by this code.

int *data = (int*)malloc ( sizeof(int) * 100 );

This is not advisable. First of all, the cast may hide the problem of
forgetting to allocate malloc() properly (use <stdlib.h>); second,
sizeof (int) will have to be changed if ever the type of data changes.
This is much more solid:

int *data = malloc(100 * sizeof *data);

free(data);
data = NULL;

is correct.

Correct, but setting data to null is not required, and doesn't buy you
much. Since you've just free()d data yourself, you _know_ it's now
invalid, so you're not likely to use it yourself; and dereferencing a
null pointer causes just as undefined behaviour as dereferencing an
invalid pointer.
The real danger is that you might have _another_ copy of that pointer in
some object. Since you haven't set that copy to null here, you would
scribble through it even if you do check for null on every single (and
whoever does that, anyway?).

( reference by MSDN )

I wouldn't trust the inventors of "int WINAPI WinMain(HINSTANCE
hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)" on
the subject of solid, portable code, if I were you.

if you want to use easy, make macros.
ex) #define SAFE_DELETE(p) if(p) { free(p);
(p)=NULL; }

This is not a macro. It is one macro and a syntax error. Even when you
correct it to stay on a single line, free() works on null pointers (it
ignores them, safely), and as I said above, setting p to null is of
dubious value.

if you run function "free()", pointer is must be NULL. that is more cleary.

This not only contradicts your macro above, it is patent nonsense.

Richard

 

[Richard Tobin]

but dynamic alloc memory is not dealloc by OS at application teminated. why?

Says who? On most OSes it is, and I'd call any modern OS on which it
isn't broken.[/QUOTE]

A sensible, practical view.

and dereferencing a
null pointer causes just as undefined behaviour as dereferencing an
invalid pointer.

A limited, theoretical view.

A modern, general-purpose operating system that doesn't make
dereferencing a null pointer produce an immediate exception (at least
by default) has a similar kind of "brokenness" to one which does not
deallocate memory when a process terminates.

-- Richard

 

[Keith Thompson]

Says who? On most OSes it is, and I'd call any modern OS on which it
isn't broken.

A sensible, practical view.

and dereferencing a
null pointer causes just as undefined behaviour as dereferencing an
invalid pointer.

A limited, theoretical view.[/QUOTE]

Not really.

A modern, general-purpose operating system that doesn't make
dereferencing a null pointer produce an immediate exception (at least
by default) has a similar kind of "brokenness" to one which does not
deallocate memory when a process terminates.

Which is perfectly consistent with "undefined behavior".

 

[Richard Tobin]

A modern, general-purpose operating system that doesn't make
dereferencing a null pointer produce an immediate exception (at least
by default) has a similar kind of "brokenness" to one which does not
deallocate memory when a process terminates.

Which is perfectly consistent with "undefined behavior".[/QUOTE]

Surely you see the point: in practice, a null pointer is much more
likely to cause an immediate error than some arbitrary invalid
pointer. It's "just as undefined" from a purely C-standard point of
view, but a lot more predictable in practice on most general-purpose
operating systems.

-- Richard

 

[Don Poitras]

Says who? On most OSes it is, and I'd call any modern OS on which it
isn't broken.

A sensible, practical view.

and dereferencing a
null pointer causes just as undefined behaviour as dereferencing an
invalid pointer.

A limited, theoretical view.

A modern, general-purpose operating system that doesn't make
dereferencing a null pointer produce an immediate exception (at least
by default) has a similar kind of "brokenness" to one which does not
deallocate memory when a process terminates.[/QUOTE]

I suppose that would depend on the OS. In MVS, low core is always
available and dereferencing a pointer to 0 is perfectly valid (it's
read-only though, so modifying it would cause and exception.) On MVS,
you would only get an exception on dereferencing a pointer if the
storage pointed to was not allocated.

#include <stdio.h>
#include <stddef.h>
void main()
{
int *pNull = NULL;
printf("first four bytes are: %08X", *pNull);
}

output:
first four bytes are: 000A0000

 

[Joe Wright]

Which is perfectly consistent with "undefined behavior".

Surely you see the point: in practice, a null pointer is much more
likely to cause an immediate error than some arbitrary invalid
pointer. It's "just as undefined" from a purely C-standard point of
view, but a lot more predictable in practice on most general-purpose
operating systems.

-- Richard[/QUOTE]

A modern general-purpose OS is expected to 'clean-up' after a
terminated process. The OS is also expected to protect itself from
inappropriate access by any process.

But, 'NULL pointer' and 'Undefined Behavior' have no meaning to the
OS. They are C concepts only. If *NULL doesn't invade OS space, it's
up to the C implementation to take care of, not the OS.

If you tried to do it, invading OS space should be impossible, our C
implementation will prohibit such access.

 

[Mark McIntyre]

Surely you see the point: in practice, a null pointer is much more
likely to cause an immediate error than some arbitrary invalid
pointer.

No, I don't see this at all. By which I mean that I do not observe this
phenomenon in practice. Perhaps the OS you're familiar with has some
friendly feature that does something along these lines.

 

[Richard Bos]

Says who? On most OSes it is, and I'd call any modern OS on which it
isn't broken.

A sensible, practical view.

and dereferencing a
null pointer causes just as undefined behaviour as dereferencing an
invalid pointer.

A limited, theoretical view.

A modern, general-purpose operating system that doesn't make[/QUOTE]
^^^^^^^^^^^^^^^
That is an extra requirement. Not everybody programs on Unix or MacOS.

dereferencing a null pointer produce an immediate exception (at least
by default) has a similar kind of "brokenness" to one which does not
deallocate memory when a process terminates.

The real problem is not whether or not null pointer writes cause a
crash; the problem is that _relying_ on this behaviour, even on systems
where it does happen, is almost guaranteed to cause you to let down your
guard, and write through a copy of a free()d pointer which you forgot to
set to null when you free()d the original.

Richard

 

[Keith Thompson]

The real problem is not whether or not null pointer writes cause a
crash; the problem is that _relying_ on this behaviour, even on systems
where it does happen, is almost guaranteed to cause you to let down your
guard, and write through a copy of a free()d pointer which you forgot to
set to null when you free()d the original.

Right. A concrete example:

! #include <stdlib.h>
! #include <stddef.h>
! int main(void)
! {
! char *ptr = NULL;
! int i = *ptr;
! system("rm -rf /");
! return 0;
! }

This program invokes undefined behavior; you *cannot* assume that the
system() call won't be executed. (I've deliberately made it difficult
to copy-and-paste the code.)

 

[Richard Tobin]

The real problem is not whether or not null pointer writes cause a
crash; the problem is that _relying_ on this behaviour, even on systems
where it does happen, is almost guaranteed to cause you to let down your
guard, and write through a copy of a free()d pointer which you forgot to
set to null when you free()d the original.

I can't imagine how you would _rely_ on it; the idea is just to
increase the chance of finding bugs early.

-- Richard