linux-kernel - RE: Why is the kfree() argument const?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jan 2008 16:56:02 -0800
From:	"David Schwartz" <davids@...master.com>
To:	<torvalds@...ux-foundation.org>
Cc:	"Johannes Weiner" <hannes@...urebad.de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	<clameter@....com>, <penberg@...helsinki.fi>
Subject: RE: Why is the kfree() argument const?

> On Thu, 17 Jan 2008, David Schwartz wrote:

> > No, that's not what it means. It has nothing to do with memory.
> > It has to do
> > with logical state.

> Blah. That's just your own made-up explanation of what you think "const"
> should mean. It has no logical background or any basis in the C language.

To some extent, I agree. You can use "const" for pretty much any reason.
It's just a way to say that you have a pointer and you would like an error
if certain things are done with it.

You could use it to mean anything you want it to mean. The most common use,
and the one intended, is to indicate that an object's logical state will not
be changed through that pointer.

> "const" has nothing to do with "logical state".  It has one meaning, and
> one meaning only: the compiler should complain if that particular type is
> used to do a write access.

Right, exactly.

> It says nothing at all about the "logical state of the object".
> It cannot,
> since a single object can - and does - have multiple pointers to it.

You are the only one who has suggested it has anything to do with changes
through other pointers or in other ways. So you are arguing against only
yourself here.

Nobody has said it has anything to do with anything but operations through
that pointer.

> So your standpoint not only has no relevant background to it, it's also
> not even logically consistent.

Actually, that is true of your position. On the one hand, you defend it
because kfree does not change the data. On the other hand, you claim that it
has nothing to do with whether or not the data is changed.

The normal use of "const" is to indicate that the logical state of the
object should not be changed through that pointer. The 'kfree' function
changes the logical state of the object. So, logically, 'kfree' should not
be const.

The usefulness of "const" is that you get an error if you unexpectedly
modify something you weren't expected to modify. If you are 'kfree'ing an
object that is supposed to be logically immutable, you should be made to
indicate that you are aware the object is logically immutable.

Simply put, you you have to cast in any case where you mean to do something
that you want to get an error in if you do not cast. I would like to get an
error if I call 'kfree' through a const pointer, because that often is an
error. I may have a const pointer because my caller still plans to use the
object.

Honestly, I find your position bizarre.

DS

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