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]

Message-ID: <20080118172428.GB61848@dspnet.fr.eu.org>
Date:	Fri, 18 Jan 2008 18:24:29 +0100
From:	Olivier Galibert <galibert@...ox.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote:
> I'd say this implies the exact opposite.  It almost sounds like the 
> compiler is free to change:
> 
> void foo(const int *x);
> foo(x);
> printf("%d", x);
> 
> to:
> 
> void foo(const int *x);
> printf("%d", x);
> foo(x);

That's only if neither function has side effects noticeable by the
other.  Invalidating the pointer in (k)free is rather noticeable.

> (Note that this isn't just a problem for optimizers -- a programmer 
> might expect that passing a pointer to a function that takes a const 
> pointer argument does not, in and of itself, change the pointed-to 
> value.  Given that const certainly does not mean that no one else 
> changes the object, I'm not sure what else it could mean.

Most of the time, const pointer arguments means "I won't change the
contents of the object so that you'll notice by reading it in a normal
way afterwards".  That's pretty much what mutable in a variety of
languages (including C++) is about, saying "this field is internal
management stuff not visible from the external interface, so I need to
be able to change it even through const pointers I got as parameters".
Reference counters for copy-on-write setups is the usual example of
use.

In the case of deallocation functions you are not allowed to do
anything through the pointer or its aliases after the function
returns.  So we're outside of the "most of the time" case, since
you're not allowed to try to notice any change.  Pragmatism takes
over, you want the type that catches as many possible types as
possible while staying reasonable (volatile is never reasonable), and
that's const void *.  As simple as that.

As for releasing resources through const pointers, that happens all
the time as soon as your const use is tight, and if you think forcing
the systematic addition of a (void *) cast is going to make your code
more readable, well, you need more experience in maintaining other
people's applications.

> kfree does not have either property, so I'm don't think it makes
> sense for it to take a const argument.

delete in C++ allows const pointers. Think about it.

  OG.
--
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/