Calling free() on an uninitialised pointer?

[santosh]

Hi,

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?

Thanks for your time.

 

[Nick Keighley]

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

a program that does this exhibits undefined behaviour. It *may*
return harmlessly or give a segmentation error or something even
nastier. Don't ever do this.

what is safe is:-
p = NULL;
free(p);

Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?

no

 

[Emmanuel Delahaye]

santosh a écrit :

Hi,

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

Undefined behaviour. A serious bug. Don't do that. Never.

Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?

Make it point to NULL by default or once free() has been performed. I
recommend this construction :

free(p), p = NULL;

It makes it easy to test, and it happens that free (NULL) is defined and
harmless.

 

[Christian Bau]

Hi,

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

First, it is undefined behavior, so _anything_ can happen. Especially,
it might return harmlessly every time you do this while you are
developping your program, and the first time it is used seriously it
could crash the computer it is running on and cause considerable
financial damage. Don't do this.

What exactly happens depends on your implementation. The value of an
uninitialised pointer variable might by great coincidence be the same as
some pointer variable that was initialised by calling malloc. In that
case, calling free () will free that pointer, with likely harmful
consequences. That is not as unlikely as it seems, because an
uninitialised variable might be kept in a register that happens to
contain another completely unrelated variable of the calling function.

 

[Daniel Rudy]

At about the time of 12/4/2005 2:17 AM, santosh stated the following:

Hi,

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

Maybe, maybe not. The behavior is undefined. Undefined meaning that
*ANYTHING* can happen, including your harddisk being reformatted (Which
is admittidly an extream case).

Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?

What I do is initialize all pointers to NULL when my program starts and
on entries to functions right in the initialzation section. This is a
good practice as it gives you a known starting point to go from.

int ptest(int size)
{
void *p;

p = NULL;
p = malloc(size);
if (p == NULL) return(-1);
/* perform some action here */
free(p);
return(0);
}

In this case here, p can never have an unknown value. If the call to
malloc fails, then malloc returns NULL, which can be tested for. Get
into the habbit of setting all your pointers to NULL before and after
you use them.

Thanks for your time.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Joe Wright]

Hi,

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

Undefined behavior. You can call free() once and only once on a pointer
value returned by malloc & company. You can free(NULL) with no effect.

Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?

There is no way to determine by inspection the validity of any pointer
value. The only pointer value that you are guaranteed to know something
about is NULL and that it doesn't 'point' to anything.

Thanks for your time.

I've never had any real problem with the malloc()/free() stuff probably
because of programming habit. I always write the beginning and end of
functions at the same time. For example I begin a generic program with..

#include <stdio.h>

int main(void) {

return 0;
}

...and only then, fill it in with code. I tend to do the same with
malloc/free and fopen/fclose. Properly written, whether to free or
fclose is not the question, just do it.

 

[Artie Gold]

santosh a écrit :



Undefined behaviour. A serious bug. Don't do that. Never.



Make it point to NULL by default or once free() has been performed. I
recommend this construction :

free(p), p = NULL;

It makes it easy to test, and it happens that free (NULL) is defined and
harmless.

Unfortunately, there are cases where doing so will mask a logic error
wherein otherwise a pointer would be free()-ed twice. So be careful.

HTH,
--ag

 

[Keith Thompson]

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

This is, of course undefined behavior, but not because of the call to
free(). Any attempt to evaluate an uninitialized pointer variable
invokes undefined behavior. For example:

int *ptr; /* uninitialized */
if (ptr == NULL) ...; /* undefined behavior */

Realistically, the call to free() is more likely to cause something
bad to happen than the evaluation of the argument.

 

[Jordan Abel]

Unfortunately, there are cases where doing so will mask a logic error
wherein otherwise a pointer would be free()-ed twice. So be careful.

it'll mask it or solve it? setting it to null guarantees that it won't
be freed twice, so this is hardly a "mask" - it actually changes the
logic to prevent the error

 

[santosh]

This is, of course undefined behavior, but not because of the call to
free(). Any attempt to evaluate an uninitialized pointer variable
invokes undefined behavior. For example:

int *ptr; /* uninitialized */
if (ptr == NULL) ...; /* undefined behavior */

Realistically, the call to free() is more likely to cause something
bad to happen than the evaluation of the argument.

Thank you all for your clear replies.

To sum up, if I understand correctly, good programming implies
that a pointer must either be NULL or must contain a known
value, returned by malloc() and co.

And if I do want to manipulate the lvalue, it is better to make a
copy of the original pointer and deal with it. The lvalue must also
be unchanged (i.e. the one that malloc() returned), when the pointer
is passed to free().

Are the above assumptions correct?

Is even using the address of operator on an uninitialised pointer
undefined?

Thanks all.

 

[Kenneth Brody]

Hi,

If I call free() with a uninitialised pointer, will the program
state become undefined, or will free() return harmlessly?

Even if passing an invalid pointer to free() were permitted, imagine
what would happen if this uninitialized pointer just happened to have
the same value as a previously malloc'ed buffer. That alone should
be enough to understand why this must be undefined behavior.

Incidentally, is there a way in Standard C to determine
weather a pointer points to a valid block of allocated
memory?

No. I suppose you could put wrappers around malloc/calloc/recalloc/free
which tracks all allocated buffers, and then supply a function to check
if a pointer is in the list. This would, of course, only keep track of
your memory allocations, and not anything done within any library calls.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[pete]

santosh wrote:

Is even using the address of operator on an uninitialised pointer
undefined?

No.
The address of an object
does not depend on the value of the object.
Accessing the value of an uninitialised object,
is where the problems come from.

Likewise, the identifier of an uninitialised object
can be a valid operand of the sizeof operator.

 

[Artie Gold]

it'll mask it or solve it? setting it to null guarantees that it won't
be freed twice, so this is hardly a "mask" - it actually changes the
logic to prevent the error

Perhaps.

It *will* avoid the UB -- but why, outside of very specific situations
(where the programmer knows *exactly* what he/she is doing) would one
free() the memory associated with a pointer more than once? And could it
be a case of mistakenly free()-ing the *wrong* pointer, introducing a
memory leak?

Too often, such constructions are used more as a band-aid than as a well
considered design decision (as it might be in the case of cleanup code
after failed resource acquisition, for example).

Just my .02.

HTH,
--ag

 

[Keith Thompson]

Thank you all for your clear replies.

To sum up, if I understand correctly, good programming implies
that a pointer must either be NULL or must contain a known
value, returned by malloc() and co.

A pointer can also contain the address of a declared object. If
you're not careful, this can cause similar problems if the object
ceases to exist before the pointer does. For example:

int *func(void)
{
int local_var;
return &local_var;
}

local_var ceases to exist when func() returns, but the caller now has
a pointer to this nonexistent object. If the caller attempts to use
this pointer value, it will invoke undefined behavior.

If you need to do this kind of thing, there are several workarounds.
You can declare local_var as static (which means every call to func()
will return the same address), or you can allocate the space with
malloc() (which means it's up to the caller to free() it), or you can
pass a pointer *into* the function and let the function assign a value
to the pointed-to object (which means the caller has to know -- or
guess -- how much space to allocate). This isn't likely to be an
issue for a pointer to int, but it's common when you want your
function to return an array, such as a string.