Passing const void* to free()

[Peter Ammon]

Often times, I'll have some malloc()'d data in a struct that need not
change throughout the lifetime of the instance of the struct.
Therefore, the field within the struct is declared a pointer to const
[something]. But then free() complains when I pass in the pointer
because free() is declared as void free(void*). So I have to cast.

Why is it not declared as void free(const void*), which would save me
these headaches?

-Peter

[Ben Pfaff]

Peter Ammon <pe*********@ro cketmail.com> writes:

Why is it not declared as void free(const void*), which would save me
these headaches?

Because that would make it easily possible to try to free data
that is actually defined as constant. You can always define your
own function for freeing "const" data:
void free_const(cons t void *p) { free((void *) p); }
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

[Dan Pop]

In <cc*********@ne ws.apple.com> Peter Ammon <pe*********@ro cketmail.com> writes:

Often times, I'll have some malloc()'d data in a struct that need not
change throughout the lifetime of the instance of the struct.
Therefore, the field within the struct is declared a pointer to const
[something]. But then free() complains when I pass in the pointer
because free() is declared as void free(void*). So I have to cast.
Welcome to the world of const poisoning. Don't use const and your
troubles are gone.
Why is it not declared as void free(const void*), which would save me
these headaches?

Because it would be semantically incorrect: this declaration promises
you that free() won't modify the data pointed to by its parameter. Or
the free() function is specified as *destroying* this data.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Emmanuel Delahaye]

In 'comp.lang.c', Da*****@cern.ch (Dan Pop) wrote:

Because it would be semantically incorrect: this declaration promises
you that free() won't modify the data pointed to by its parameter. Or ----------------------------------------------------------------------^
Frenchism ? Do you mean 'thus' or 'however' ? Just kidding!
the free() function is specified as *destroying* this data.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.c h> spoke thus:

Welcome to the world of const poisoning. Don't use const and your
troubles are gone.

But if things are really const, doesn't it make some sense from a
design standpoint to declare them as such?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Arthur J. O'Dwyer]

On Wed, 7 Jul 2004, Christopher Benson-Manica wrote:

Dan Pop <Da*****@cern.c h> spoke thus:

Welcome to the world of const poisoning. Don't use const and your
troubles are gone.

But if things are really const, doesn't it make some sense from a
design standpoint to declare them as such?

Of course. But Peter Ammon was declaring something as 'const' that
patently was *not* constant --- its target was being allocated and
de-allocated (changing the contents of the pointer variable as well
as the contents of the target) during its own lifetime.

"Const poisoning" is certainly an annoying problem when it arises,
but it *usually* indicates poor design, not a flaw in the language.
Certainly in this case it's a symptom of poor design --- if you're
malloc'ing and free'ing an object, it certainly shouldn't be 'const'!

-Arthur

[Jack Klein]

On 7 Jul 2004 13:09:02 GMT, Da*****@cern.ch (Dan Pop) wrote in
comp.lang.c:

In <cc*********@ne ws.apple.com> Peter Ammon <pe*********@ro cketmail.com> writes:

Often times, I'll have some malloc()'d data in a struct that need not
change throughout the lifetime of the instance of the struct.
Therefore, the field within the struct is declared a pointer to const
[something]. But then free() complains when I pass in the pointer
because free() is declared as void free(void*). So I have to cast.

Welcome to the world of const poisoning. Don't use const and your
troubles are gone.

Why is it not declared as void free(const void*), which would save me
these headaches?

Because it would be semantically incorrect: this declaration promises
you that free() won't modify the data pointed to by its parameter. Or
the free() function is specified as *destroying* this data.

No, it is defined to do no such thing.

<quote>
7.20.3.2 The free function

Synopsis

1 #include <stdlib.h>
void free(void *ptr);

Description

2 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. Otherwise, if the argument does not
match a pointer earlier returned by the calloc, malloc, or realloc
function, or if the space has been deallocated by a call to free or
realloc, the behavior is undefined.

Returns

3 The free function returns no value.
<end quote>

Not one single word about destroying the data, or indeed any
specification at all about what happens to the contents of the memory.
In point of fact, a strictly conforming program cannot determine
whether the contents of the memory is modified in any way or not.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Stephen Sprunk]

"Jack Klein" <ja*******@spam cop.net> wrote in message
news:pg******** *************** *********@4ax.c om...

Not one single word about destroying the data, or indeed any
specification at all about what happens to the contents of the memory.
In point of fact, a strictly conforming program cannot determine
whether the contents of the memory is modified in any way or not.

The contents of the memory might not be modified, but any use of the pointer
itself becomes undefined after calling free(), so the semantics of the
argument have changed even if the value might not have. Declaring free()'s
argument as const would be nonsensical as the pointer does not have the same
semantics after the call as it did before the call, and the value of the
pointed-to memory is undefined as well.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

[Dan Pop]

In <pg************ *************** *****@4ax.com> Jack Klein <ja*******@spam cop.net> writes:

On 7 Jul 2004 13:09:02 GMT, Da*****@cern.ch (Dan Pop) wrote in
comp.lang.c:

In <cc*********@ne ws.apple.com> Peter Ammon <pe*********@ro cketmail.com> writes:

>Often times, I'll have some malloc()'d data in a struct that need not
>change throughout the lifetime of the instance of the struct.
>Therefore, the field within the struct is declared a pointer to const
>[something]. But then free() complains when I pass in the pointer
>because free() is declared as void free(void*). So I have to cast.

Welcome to the world of const poisoning. Don't use const and your
troubles are gone.

>Why is it not declared as void free(const void*), which would save me
>these headaches?

Because it would be semantically incorrect: this declaration promises
you that free() won't modify the data pointed to by its parameter. Or
the free() function is specified as *destroying* this data.

No, it is defined to do no such thing.

<quote>
7.20.3.2 The free function

Synopsis

1 #include <stdlib.h>
void free(void *ptr);

Description

2 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. Otherwise, if the argument does not
match a pointer earlier returned by the calloc, malloc, or realloc
function, or if the space has been deallocated by a call to free or
realloc, the behavior is undefined.

Returns

3 The free function returns no value.
<end quote>

Not one single word about destroying the data, or indeed any
specificatio n at all about what happens to the contents of the memory.
In point of fact, a strictly conforming program cannot determine
whether the contents of the memory is modified in any way or not.

Learn to read, Jack, learn to read. If a block is deallocated, what
happens to the data it contained before deallocation? It becomes
irreversibly inaccessible, so *for all intents and purposes* it is
destroyed. No one cares whether it was actually touched by the execution
of free(), this is immaterial.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Xn************ *************** @212.27.42.72> Emmanuel Delahaye <em**********@n oos.fr> writes:

In 'comp.lang.c', Da*****@cern.ch (Dan Pop) wrote:

Because it would be semantically incorrect: this declaration promises
you that free() won't modify the data pointed to by its parameter. Or

----------------------------------------------------------------------^
Frenchism ? Do you mean 'thus' or 'however' ? Just kidding!

^^^^^^^^^
I am not a native French speaker, so whatever mistakes I make are very
unlikely to be caused by my French ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de