free()

[dbansal]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc(). now I am trying to free that memory
using free((void*)ptr). My question is does free() make ptr NULL? If
not how do we know whether ptr memory has been freed already and we
should not try to free the same memory twice. Man pages does not tell
anything about this behavoiur.

Thanks,

 

[Ian Collins]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc().

I very much doubt it. Have a look a the the scores of messages over the
past couple of days regarding the correct use of malloc.

now I am trying to free that memory
using free((void*)ptr).

Why on Earth would you cast the pointer?

My question is does free() make ptr NULL?

No, how could it?

If not how do we know whether ptr memory has been freed already and we
should not try to free the same memory twice. Man pages does not tell
anything about this behavoiur.

It's undefined behaviour. You have to manage your own pointers.

 

[Richard Heathfield]

dbansal said:

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc().

Drop the pointless obfuscatory cast.

now I am trying to free that memory
using free((void*)ptr).

And that one.

My question is does free() make ptr NULL?
No.

If
not how do we know whether ptr memory has been freed already

free(ptr);
ptr = NULL;

 

[tphipps1]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc(). now I am trying to free that memory
using free((void*)ptr). My question is does free() make ptr NULL?

You have no clue what you're talking about. Think about it for one
tiny second... free is a function that's passed ptr by value, so how
on earth do you imagine it could set it to NULL?

If
not how do we know whether ptr memory has been freed already and we
should not try to free the same memory twice. Man pages does not tell
anything about this behavoiur.

Maybe the writers of the man pages assumed their readers would have
some small amount of intelligence and/or have invested some time in
learning the C language before trying to program in it?

 

[santosh]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc().

The cast is not needed, indeed even counterproductive, in C.

now I am trying to free that memory
using free((void*)ptr).

Same as above.

My question is does free() make ptr NULL?
No.

If not how do we know whether ptr memory has been freed already and we
should not try to free the same memory twice. Man pages does not tell
anything about this behavoiur.

As long as you pass a value previously obtained from malloc() calloc()
or realloc(), free() will succeed. If the argument is a null pointer
value, free() does nothing.

There's no mechanism in C to tell you if a pointer value points to
validly addressable memory or not. You'll have to keep track of such
things yourself. One safe practise is to immediately set a pointer to
NULL after calling free() on it. Passing a null pointer to free() is
harmless.

 

[Kenny McCormack]

I very much doubt it.

How can you say this? I don't doubt it at all (that he did what he says
he did).

Anyway, sounds like the OP should add this to his toolkit:

void myfree(void **ptr) {
free(*ptr);
*ptr = NULL;
}

 

[Richard Heathfield]

Kenny McCormack said:

How can you say this?

Because it won't compile.

I don't doubt it at all (that he did what he says he did).
Figures.


Anyway, sounds like the OP should add this to his toolkit:

void myfree(void **ptr) {
free(*ptr);
*ptr = NULL;
}

The problem with that is that you can't pass anything to it, except the
address of a void pointer. void ** does not have the same guarantees as
void *.

 

[Guest]

How can you say this? I don't doubt it at all (that he did what he says
he did).

I doubt that he managed to call malloc without passing it any
argument.

Anyway, sounds like the OP should add this to his toolkit:

void myfree(void **ptr) {
free(*ptr);
*ptr = NULL;
}

ptr is probably declared as a pointer to int (judging from the cast),
so myfree(&ptr) won't work. If you want to always set a freed pointer
of any type to NULL, you'll need either compiler-specific extensions,
or you'll need a macro.
#define myfree(p) (free(p), p = NULL)
Of course, the usual problems apply, but I'm sure you know them
already.

 

[Mark McIntyre]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc(). now I am trying to free that memory
using free((void*)ptr).

Neither of those casts is necessary, and if you're writing C, it is
strongly recommended by most experts that you don't insert them.

My question is does free() make ptr NULL?
No.

If not how do we know whether ptr memory has been freed already

free()ing a null pointer is safe.

7.20.3.2 The free function
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.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Martin Ambuhl]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc(). now I am trying to free that memory

^^^^^^^^^^^^^^^^^^
The cast to (int *) is unnecessary and poor style.
malloc requires an argument; not supplying one is an error.
No matter what kind of argument ptr points to (but it should be a pointer)
ptr = malloc(sizeof *ptr);
will work, but you should check to see that the result is not NULL.

using free((void*)ptr).

The cast to (void *) is unnecessary and poor style.

My question is does free() make ptr NULL?

No, but you haven't learned enough C to be bothered with such questions yet.

If
not how do we know whether ptr memory has been freed already

You hire a competent programmer.

 

[Keith Thompson]

There's no mechanism in C to tell you if a pointer value points to
validly addressable memory or not. You'll have to keep track of such
things yourself. One safe practise is to immediately set a pointer to
NULL after calling free() on it. Passing a null pointer to free() is
harmless.

That's only relatively safe; if you've made copies of the pointer
before free()ing it, those copies become indeterminate.

 

[HyperCube]

Hi group,

I have a question to ask you all. I have allocated some chunk of
memory using ptr=(int*)malloc(). now I am trying to free that memory
using free((void*)ptr). My question is does free() make ptr NULL? If
not how do we know whether ptr memory has been freed already and we
should not try to free the same memory twice. Man pages does not tell
anything about this behavoiur.

Thanks,

Sure not. free() marks the allocated memory chunk to 'not in use'
state, that means your program has lost control to the chunk, and this
chunk can be TAKEN BY SOME OTHER CODE. And the value of your pa
remains unchanged, THIS IS VERY DANGEROUS, because you may try to read/
write the memory space which not belongs to you, this behavior will
cause an security alert on most operating systems.

 

[Racaille]

things yourself. One safe practise is to immediately set a pointer to
NULL after calling free() on it. Passing a null pointer to free() is
harmless.

this is a very bad idea.

instead of having your code crash like hell in the
first phases of debugging, which will allow you
to fix the thing quick & properly, you will happily
call free() many times on the same pointer, and
build crap around that broken logic, and then
call for a garbage collector

 

[Richard Heathfield]

Racaille said:

this is a very bad idea.

Setting pointers to NULL after a free() is a very good idea indeed.
Having indeterminate values around the place is a bad idea. I agree
that passing a null pointer to free() indicates a design flaw.

instead of having your code crash like hell in the
first phases of debugging, which will allow you
to fix the thing quick & properly,

Chapter and verse, please. Where does the Standard guarantee that your
code will crash like hell when you pass a pointer to free() a second
time?

you will happily call free() many times on the same pointer, and
build crap around that broken logic, and then call for a garbage
collector

Will I really? How long does that process take, from the time I first
decide not to let indeterminate values plague my debugging to the time
I first call for a garbage collector?

 

[Racaille]

Setting pointers to NULL after a free() is a very good idea indeed.
Having indeterminate values around the place is a bad idea. I agree
that passing a null pointer to free() indicates a design flaw.

What's your point ?
santosh was suggesting to set the pointer to NULL in order to be able
to 'safely' call free() again on it - first you say that this is a
'very
good idea', then that it indicates a 'design flaw'.

As of indeterminate values, you have them floating around all the time
-
otherwise you would be able (like God) to resolve everything at
compile time.

That is pure sophistry - please try to be honest and don't abuse your
better
control of English to push that crap.

Chapter and verse, please. Where does the Standard guarantee that your
code will crash like hell when you pass a pointer to free() a second
time?

Better you tell me how to (chapter/verse-) portably 0xdeadbeef a
pointer.

How to portably generate an 'invalid' pointer. NULL/0 doesn't qualify,
since it's common practice for interfaces to either ignore NULL
pointers
(see free()) or to interpret them as 'default value'.

Will I really? How long does that process take, from the time I first
decide not to let indeterminate values plague my debugging to the time
I first call for a garbage collector?

I don't know - how much does it take from the first time I decided not
to
let the dihydrogen monoxide plague my life to the time I will be
generation-scavangered ?

 

[Chris Dollin]

Better you tell me how to (chapter/verse-) portably 0xdeadbeef a
pointer.

How to portably generate an 'invalid' pointer. NULL/0 doesn't qualify,
since it's common practice for interfaces to either ignore NULL
pointers
(see free()) or to interpret them as 'default value'.

I'm sure I'm misunderstanding what you're asking for, but the
sequence:

void *spoo = malloc(1);
free( spoo );

makes `spoo` an invalid pointer.

Of course, /because/ it's invalid, you can't use it for anything,
so I'm not sure what you wanted it for -- see first sentence ...

 

[Richard Heathfield]

Racaille said:

What's your point ?

I have two - firstly that the issue of setting indeterminate pointer
values to NULL is actually a good idea (so I disagree with you there),
and secondly that passing a null pointer to free() indicates a badly
written program (so I agree with you there). Did I not make this clear?

santosh was suggesting to set the pointer to NULL in order to be able
to 'safely' call free() again on it - first you say that this is a
'very
good idea', then that it indicates a 'design flaw'.

Two separate issues.

As of indeterminate values, you have them floating around all the time

No, I don't.

-
otherwise you would be able (like God) to resolve everything at
compile time.

I don't see why that follows. Please explain further.

That is pure sophistry - please try to be honest and don't abuse your
better control of English to push that crap.

It is not sophistry, I am being honest, I don't see what my use of
English has to do with this, and I'm not pushing anything - so I'm
afraid you're 100% wrong there.

Better you tell me how to (chapter/verse-) portably 0xdeadbeef a
pointer.

If you mean "how can I set a pointer to a value which I can reliably
interrogate to ensure that I can know that dereferencing the pointer
would be invalid?", the answer is simple: ptr = NULL;

How to portably generate an 'invalid' pointer.

ptr = NULL;

NULL/0 doesn't qualify,

Yes, it does.

since it's common practice for interfaces to either ignore NULL
pointers

That's their problem (or opportunity, or feature, or whatever you like
to call it), not mine.

(see free()) or to interpret them as 'default value'.

See above.

 

[santosh]

this is a very bad idea.

instead of having your code crash like hell in the
first phases of debugging, which will allow you
to fix the thing quick & properly, you will happily
call free() many times on the same pointer, and
build crap around that broken logic, and then
call for a garbage collector

I argue that attempting to ensure that pointers are either null or
have legally deferencible values is better. A null pointer is by
definition an unusable pointer. A pointer with an indeterminate value,
on the other hand, may or may not exhibit observable error, when
misused. I prefer to take the more deterministic route.

 

[Richard Bos]

I argue that attempting to ensure that pointers are either null or
have legally deferencible values is better.

The problem with that is "attempting". You will, sooner or later, fail
in your attempt. And then, because you believe that all your pointers
are either null or valid, you will not be able to find the bug until
someone else points it out to you. Making sure that you know which of
your pointers are still in use _is_ possible, and does not have this
problem.

Richard

 

[Ian Collins]

The problem with that is "attempting". You will, sooner or later, fail
in your attempt. And then, because you believe that all your pointers
are either null or valid, you will not be able to find the bug until
someone else points it out to you. Making sure that you know which of
your pointers are still in use _is_ possible, and does not have this
problem.

Can you cite an example where setting a pointer to NULL could mask a
bug? The way I see it is there are three things you can do with a
pointer, test it, dereference it and free it. Once set to NULL, the
first to will fail and the third is harmless.