From: Olivier Galibert <galibert@pobox.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Why is the kfree() argument const?
Date: Fri, 18 Jan 2008 18:24:29 +0100 [thread overview]
Message-ID: <20080118172428.GB61848@dspnet.fr.eu.org> (raw)
In-Reply-To: <4790AF68.8040403@myrealbox.com>
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.
next prev parent reply other threads:[~2008-01-18 17:24 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <MDEHLPKNGKAHNMBLJOLKIEGIJJAC.davids@webmaster.com>
2008-01-17 21:25 ` Linus Torvalds
2008-01-17 22:28 ` David Schwartz
2008-01-17 23:10 ` Linus Torvalds
2008-01-18 0:56 ` David Schwartz
2008-01-18 1:15 ` Linus Torvalds
2008-01-18 5:02 ` David Schwartz
2008-01-18 15:38 ` Chris Friesen
2008-01-18 16:10 ` Linus Torvalds
2008-01-18 20:55 ` David Schwartz
2008-01-18 17:37 ` Olivier Galibert
2008-01-18 18:06 ` DM
2008-01-18 7:51 ` Giacomo Catenazzi
2008-01-18 8:20 ` Giacomo Catenazzi
2008-01-18 13:53 ` Andy Lutomirski
2008-01-18 17:24 ` Olivier Galibert [this message]
2008-01-18 22:29 ` J.A. Magallón
2008-01-18 23:44 ` Krzysztof Halasa
2008-01-18 13:54 ` Andy Lutomirski
2008-01-18 19:14 ` Vadim Lobanov
2008-01-18 19:31 ` Zan Lynx
2008-01-18 19:55 ` Vadim Lobanov
2008-01-18 8:30 ` Vadim Lobanov
2008-01-18 9:48 ` Jakob Oestergaard
2008-01-18 11:47 ` Giacomo A. Catenazzi
2008-01-18 14:39 ` Jakob Oestergaard
2008-01-18 19:06 ` Vadim Lobanov
2008-01-18 13:31 ` Björn Steinbrink
2008-01-18 14:53 ` Jakob Oestergaard
[not found] <fa.cHMztHfqJXv7vw5O0nQ8SdTrma0@ifi.uio.no>
[not found] ` <fa.V9M+5l8C/um5KEiBtZOjbJDQmu4@ifi.uio.no>
2013-01-12 19:18 ` antoine.trux
2013-01-13 8:10 ` Chen Gang F T
2013-01-13 17:41 ` Guenter Roeck
2013-01-14 1:45 ` Chen Gang F T
2013-01-13 20:54 ` Cong Ding
2013-01-14 1:18 ` Chen Gang F T
2008-01-18 19:10 ecolbus
-- strict thread matches above, loose matches on Subject: below --
2008-01-18 16:45 ecolbus
2008-01-18 18:20 ` Olivier Galibert
2008-01-18 12:45 ecolbus
2008-01-18 15:20 ` Giacomo A. Catenazzi
2008-01-16 16:32 Johannes Weiner
2008-01-16 16:48 ` Christoph Lameter
2008-01-16 17:34 ` Bernd Petrovitsch
2008-01-16 17:45 ` Pekka J Enberg
2008-01-16 18:39 ` Linus Torvalds
2008-01-16 22:19 ` Johannes Weiner
2008-01-16 22:20 ` Christoph Lameter
2008-01-16 22:37 ` Johannes Weiner
2008-01-16 23:13 ` Johannes Weiner
2008-01-16 23:18 ` Linus Torvalds
2008-01-16 23:16 ` Linus Torvalds
2008-01-16 22:33 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080118172428.GB61848@dspnet.fr.eu.org \
--to=galibert@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®