No. It's the *pointer* that is no longer valid.
There's definitely a difference between "exists and is changed" and
"doesn't exist any more".
It's not a change to the data behind it, it's a change to the *metadata*.
Which is somethign that "const" doesn't talk about at all.
No, it's why I'm right.
"kmalloc/kfree" (or any memory manager) by definition has to play games
with pointers and do things like cast them. But the users shouldn't need
to, not for something like this.
No.
You are continuing to make the mistake that you think that "const" means
that the memory behind the pointer is not going to change.
Why do you make that mistake, when it is PROVABLY NOT TRUE!
Try this trivial program:
int main(int argc, char **argv)
{
int i;
const int *c;
i = 5;
c = &i;
i = 10;
return *c;
}
and realize that according to the C rules, if it returns anything but 10,
the compiler is *buggy*.
The fact is, that in spite of us having a "const int *", the data behind
that pointer may change.
So it doesn't matter ONE WHIT if you pass in a "const *" to "kfree()": it
does not guarantee that the data doesn't change, because the object you
point to has other pointers pointing to it.
This isn't worth discussing. It's really simple: a conforming program
CANNOT POSSIBLY TELL whether "kfree()" modified the data or not. As such,
AS FAR AS THE PROGRAM IS CONCERNED, kfree() takes a const pointer, and the
rule that "if it can be considered const, it should be marked const" comes
and says that kfree() should take a const pointer.
In other words - anythign that could ever disagree with "const *" is BY
DEFINITION buggy.
It really is that simple.
Linus
--
