mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: <torvalds@linux-foundation.org>
Cc: "Johannes Weiner" <hannes@saeurebad.de>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	<clameter@sgi.com>, <penberg@cs.helsinki.fi>
Subject: RE: Why is the kfree() argument const?
Date: Thu, 17 Jan 2008 16:56:02 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKOEIPJJAC.davids@webmaster.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0801171507570.2957@woody.linux-foundation.org>


> 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



  reply	other threads:[~2008-01-18  0:57 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 [this message]
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
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=MDEHLPKNGKAHNMBLJOLKOEIPJJAC.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=clameter@sgi.com \
    --cc=hannes@saeurebad.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=torvalds@linux-foundation.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®