Dan Pop wrote:
[color=blue]
> In <ccfd8i$8l$1@news.apple.com> Peter Ammon <peter_ammon@rocketmail.com> writes:
>
>[color=green]
>>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.[/color]
>
>
> Welcome to the world of const poisoning. Don't use const and your
> troubles are gone.[/color]
I find that casting everything to void* gets rid of a lot of troubles too.
[color=blue]
>
>[color=green]
>>Why is it not declared as void free(const void*), which would save me
>>these headaches?[/color]
>
>
> 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.
>[/color]
But free() isn't modifying the data pointed to by its parameter: it's
modifying the semantics of the value of the parameter itself, which is a
much stronger and almost totally unique side effect, very different from
modifying the data pointed to.
int* foo = some_allocated_int_somewhere();
*foo = 0;
some_function(foo);
*foo = 1;
No matter whether some_function() is declared to take an int* or a const
int*, that code is always completely legal...unless some_function()
invokes free() somewhere. Thus free() is a very special case, and "it's
not const, so it might modify what its parameter points to" doesn't
capture what's going on at all.
It's interesting to note that a similar situation arises at the other
point where C destroys memory, namely, when an automatic variable goes
out of scope:
const char* function(void) {
const char buff[] = "I am const";
return buff;
}
buff is defined to be const, but all the constness in the world can't
save it from being destroyed. So that's why IMO const isn't appropriate
for expressing "data that cannot be destroyed."
Since the only restriction on free() is that the pointer value was
returned by the alloc() family of functions (or is NULL), I see no
reason to disallow const pointers to be passed in, for the same reason
we don't disallow const pointers in functions such as strcmp().
-Peter
