Hi,
Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> "const" is a pointer type issue, and is meant to make certain mis-uses
> more visible at compile time. It has *no* other meaning, and anybody who
> thinks it has is just setting himself up for problems.
[...]
> - From a very obvious and very *real* caller perspective, "free()" really
> doesn't change the thing the pointer points to. It does something
> totally different: it makes the *pointer* itself invalid.
>
> In other words, if you think that "kfree()" changed the thing you
> free'd, you're simply wrong. It did no such thing. The memory is 100%
> the same, it's just that you cannot access it any more, and if you try,
> you'll get somebody elses memory.
>
> In other words, "kfree()" can be const.
[...]
> So never believe that "const" is some guarantee that the memory under the
> pointer doesn't change. That is *never* true. It has never been true in
> C, since there can be arbitrary pointer aliases to that memory that aren't
> actually const. If you think "const *p" means that the memory behind "p"
> is immutable, you're simply wrong.
Okay, I understood that now. A const qualifier just forbids modifying
the underlying memory _through this particular pointer_, right?
In the case of slub's kfree(), which takes a const pointer, you pass it
on to slab_free() which actually _DOES_ modification of the underlying
memory when linking the object to the freelist (as far as I understood
the code).
So if I got it right and you actually modify the memory you only got a
const pointer to, you reach a level where you _have to_ break this
policy and cast to a non-const pointer, as it is currently done in
kfree(). No?
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
