mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vadim Lobanov <vlobanov@speakeasy.net>
To: Giacomo Catenazzi <cate@cateee.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	David Schwartz <davids@webmaster.com>,
	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: Fri, 18 Jan 2008 00:30:29 -0800	[thread overview]
Message-ID: <200801180030.30801.vlobanov@speakeasy.net> (raw)
In-Reply-To: <47905A95.4030500@cateee.net>

On Thursday 17 January 2008 11:51:49 pm Giacomo Catenazzi wrote:
> Linus Torvalds wrote:
> > No, I'm saying that "const" has absolutely *zero* meaning on writes to an
> > object through _other_ pointers (or direct access) to the object.
>
> Hints: "restrict" is the C99 keyword for such requirement (or better
> "const restrict")

The restrict keyword controls aliasing, to be exact. And I'm skeptical that 
inserting const there would do anything at all.

> BTW I think C use non const free as a BIG warning about not to be
> to "smart" on optimization.

I must ask what relationship you think the const keyword has to compiler 
optimizations. I know of none, and I've yet to see that keyword cause any 
difference in the resulting assembly. It forces you to make your code clean 
and well-structured, but that's about it.

Of course, it would be an interesting experiment to potentially redefine the 
const keyword to have stronger semantics, such as having the compiler assume 
that a function taking a const pointer argument will not modify the memory 
the pointer points to, and thus saving itself a memory load in the caller 
after the function executes, as long as the data is not global. I imagine 
that this would lead to some simple and measurable optimizations, all the 
while (this is where I get into hand-waving territory) breaking a minimum 
amount of code in current existence.

But that is emphatically not how C is currently defined, and you're basically 
inventing an entirely new language... C2009 perhaps? :-)

-- Vadim Lobanov

  parent reply	other threads:[~2008-01-18  8:30 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
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 [this message]
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=200801180030.30801.vlobanov@speakeasy.net \
    --to=vlobanov@speakeasy.net \
    --cc=cate@cateee.net \
    --cc=clameter@sgi.com \
    --cc=davids@webmaster.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®