Looks like Linus is off in space again.
“const” has *never* been about the thing not being modified. Forget all
that claptrap. C does not have such a notion.
“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.
. . .
In other words, “kfree()” can be const.
– Anything that *can* take a const pointer should always do so.
Why? Because we want the types to be as tight as possible, and normal
code should need as few casts as possible.
Not so much, actually. It doesn’t make the types tighter; it just makes them different. “Tighter” has even less meaning in C than const does. At least const means something to the compiler – that it may issue certain warnings or perform certain optimizations based on an assumption of immutability and any violations of that assumption are henceforth Somebody Else’s Problem. As Linus’s example of storing a const alias for a distinctly non-const piece of kmalloc’ed memory shows, const applies only to a particular high-level-language way of referring to some memory and not to the machine-level memory itself. It marks the name or path, not the thing.
The problem with kfree is that its declaration is contrary to the very distinction both I and Linus have pointed out. Only the function parameter is considered const – not the caller’s variable which might be either const or non-const without a warning either way. Having kfree take a const pointer therefore does nothing to detect Linus’s “misuses” at compile time. If people really want to get serious about distinguishing this type of pointer from that type of pointer on the basis of something other than data type then they should use something like Cqual’s type qualifiers which are much more powerful than abusing const. The way kfree is declared does save a cast if the caller’s variable happens to be const, at the expense of forcing one within kfree itself, but I think that’s weak. Reducing casts is a good thing, but automatic promotion to const is also a kind of cast so in a sense the savings here aren’t real. Memory aliases are something that clueful programmers try to avoid, inconsistent aliases doubly so, and I’ve seen many bugs that could have been avoided if differences in const-ness were always flagged instead of automatically and silently creating a const alias for a non-const pointer. A rule of reducing visible casts (while ignoring the invisible kind) carries much less weight with me than a rule that obviously-paired functions such as kmalloc and kfree should operate on the same type.