RE: Why is the kfree() argument const?


On Thu, 17 Jan 2008, David Schwartz wrote:

Nonsense. The 'kfree' function *destroys* the object pointer to by the
pointer. How can you describe that as not doing anything to the object?

Here's an idea. Think it through.

Why don't we need write permissions to a file to unlink it?

You cannot unlink a file. Given a file, if you were to attempt to unlink it,
what directory would you remove it from?

Unlinking a file is an operation on the directory the file is in, not on the
directory itself. We do need write permissions to the directory.

If you had only a const pointer to the data in the file, you should
definitely not be able to use that pointer to find a directory the file is
in and remove it without clearly indicating you know *exactly* what you're
doing. Given just that 'const' pointer, you're not supposed to be modifying
the data and certainly using that pointer to modify anything logically above
it.

Here's a hint: because unlinking doesn't *write* to it. In fact, it
doesn't read from it either. It doesn't do any access at all to that
object, it just *removes* it.

Right. It's an operation on the directory the file is in that might have
consequences for the file.

Is the file gone after you unlink it? Yes (modulo refcounting for
aliasing
"pointers" aka filenames, but that's the same for any memory manager -
malloc/free just doesn't have any, so you could think of it as a
non-hardlinking filesystem).

The file is gone if and only if the directory was the only thing that needed
the file to exist. A file that is only on one directory "belongs to" that
directory. So write permission to the directory is all that is needed.

What you are arguing is essentially that you should be able to remove a file
from any directory it is in just because you have write access to the file's
data.

So you're the one who are speaking nonsense. Making something "not exist"
is not at all the same thing as accessing it for a write (or a read). It
is a metadata operation that doesn't conceptually change the data in any
way, shape or form - it just makes it go away.

Making something "not exist" is a modification operation on that thing.

And btw, exactly as with kfree(), a unlink() may well do something like
"disk scrubbing" for security purposes, or cancel pending writes to the
backing store. But even though it may write (or, by undoing a pending
write, effectively "change the state") to the disk sectors that used to
contain the file data, ONLY AN IDIOT would call it "writing to the file".
Because "the file" is gone. Writing to the place where the file
used to be
is a different thing.

I agree with you about that part. I can't understand why you keep thinking
this is where our disagreement lies when I've stated at least three times
that I agree about this. The issue has nothing to do with whether or not
'kfree' modifies the particular bytes pointed to. It has to do with whether
or not 'kfree' is the kind of operation one would normally want to allow on
a 'const' object.

So give it up. You're wrong. Freeing a memory area is not "writing to it"
or accessing it in *any* manner, it's an operation on another level
entirely.

Nevertheless, it's a modification operation on an object that's not supposed
to be modified.

By the way, I did think of one argument that supports your position: Suppose
you have a reference counted object. You have a 'release reference and free
if zero' function. Should it be 'const'? If not, how can a 'lookup and
reference for read' function return a const pointer to the object?

However, on balance, I think a 'release reference and free if zero' function
that operates on a const pointer is sufficiently unusual that a cast to show
you know what you're doing is not a bad thing. In this case, you know it's
safe to destroy the object through a const pointer because you *know* nobody
gave you the 'const' pointer trusting you not to destroy the object. A cast
to show you have that special knowledge is, IMO, reasonable.

DS


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: pointer as argument
    ... If you pass a pointer, the function takes a copy of the pointer. ... If you pass a reference, the function takes a copy of the reference. ... that the function takes a const pointer or a const reference as its ... David Webber ...
    (microsoft.public.vc.language)
  • Re: Why is the kfree() argument const?
    ... const pointer to, you reach a level where you _have to_ break this ... Correct and we have gcc 4.2 currently spitting out warnings because of ... Any idea how to convince gcc that this is okay? ...
    (Linux-Kernel)
  • Re: Why is the kfree() argument const?
    ... it makes the *pointer* itself invalid. ... you'll get somebody elses memory. ... In the case of slub's kfree(), which takes a const pointer, you pass it ...
    (Linux-Kernel)
  • Re: "const void * const"
    ... A const pointer to a const pointee. ... you cannot modify the pointed-to memory through p. ... void* const p is a const pointer to non-const pointee: ...
    (microsoft.public.vc.language)
  • Re: Should function argument be changed in function body?
    ... you shouldn't modify what a pointer passed in as an argument points at. ... but there are objections to overloading the return value like that also). ... You should try to avoid passing a non const pointer to a function ... int status; ...
    (comp.lang.c)
Loading