mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Chen Gang F T <chen.gang.flying.transformer@gmail.com>
Cc: antoine.trux@gmail.com, fa.linux.kernel@googlegroups.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: Sun, 13 Jan 2013 09:41:05 -0800	[thread overview]
Message-ID: <20130113174105.GA24081@roeck-us.net> (raw)
In-Reply-To: <50F26BE0.7020005@gmail.com>

On Sun, Jan 13, 2013 at 04:10:08PM +0800, Chen Gang F T wrote:
> Hello Antoine:
> 
>   after read through the whole reply of Linus Torvalds for it
>     (the time stamp is "Wed, 16 Jan 2008 10:39:00 -0800 (PST)").
> 
>   at least for me, his reply is correct in details.
> 
>   although what you said is also correct,
>   it seems you misunderstanding what he said.
> 
>   all together:
>     kfree() should use 'const void *' as parameter type
>     the free() of C Library is incorrect (it use void *).
> 
Maybe the confusion arises from the somewhat lax use of the term "const
pointer", and the csomewhat confusing way of defining variable attributes in C.
Strictly speaking,
	const char *name;
which is identical to
	char const *name;
is not a const pointer, it is a pointer to a constant (string in this case).
A "const pointer", or "constant pointer to an object", would be
	char * const name;

Guenter

> 
> 于 2013年01月13日 03:18, antoine.trux@gmail.com 写道:
> > On Wednesday, January 16, 2008 8:39:48 PM UTC+2, Linus Torvalds wrote:
> > 
> >> "const" has *never* been about the thing not being modified. Forget all 
> >> that claptrap. C does not have such a notion.
> > 
> > I beg your pardon?!
> > 
> > C has had that very notion ever since its first standard (1989). Here is an excerpt from that standard (ISO/IEC 9899:1990, section 6.5.3):
> > 
> >     "If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined."
> > 
> > 
> >> "const" is a pointer type issue, and is meant to make certain mis-uses 
> >> more visible at compile time. It has *no* other meaning, and anybody who 
> >> thinks it has is just setting himself up for problems.
> > 
> > 'const' is also a pointer issue, but not only - see above quote from the C Standard.
> > 
> > 
> > Defining an object 'const' can have an impact on optimization (and also on whether the object is placed in read-only memory). Here are trivial examples to illustrate:
> > 
> > <Program1>
> > 
> >     <foo1.c>
> >     void foo1(const int* pi)
> >     {
> >         *(int*)pi = 1;
> >     }
> >     </foo1.c>
> > 
> >     <main1.c>
> >     #include <stdio.h>
> >     void foo1(const int* pi);
> >     int main(void)
> >     {
> >         int i = 0;
> >         foo1(&i);
> >         printf("i = %d\n", i);
> >         return 0;
> >     }
> >     </main1.c>
> > 
> > </Program1>
> > 
> > Program1 defines 'i' non-const, and modifies it through a const pointer, by casting const away in foo1(). This is allowed - although not necessarily wise.
> > 
> > Program1 has well defined behavior: it prints "i = 1". The generated code dutifully retrieves the value of 'i' before passing it to printf().
> > 
> > 
> > <Program2>
> > 
> >     <foo2.c>
> >     void foo2(const int* pi)
> >     {
> >     }
> >     </foo2.c>
> > 
> >     <main2.c>
> >     #include <stdio.h>
> >     void foo2(const int* pi);
> >     int main(void)
> >     {
> >         const int i = 0;
> >         foo2(&i);
> >         printf("i = %d\n", i);
> >         return 0;
> >     }
> >     </main2.c>
> > 
> > </Program2>
> > 
> > Program2 defines 'i' const. A pointer to 'i' is passed to foo2(), which does not modify 'i'.
> > 
> > Program2 has well defined behavior: it prints "i = 0". When it generates code for main1.c, the compiler can assume that 'i' is not modified, because 'i' is defined const.
> > 
> > When compiling main2.c with gcc 4.4.7 with optimizations turned off (-O0), the generated code retrieves the value of 'i' before passing it to printf(). With optimizations turned on (-O3), it inlines the value of 'i', 0, in the call to printf(). Both versions have the same, correct behavior.
> > 
> > 
> > <Program3>
> > 
> >     <foo3.c>
> >     void foo3(const int* pi)
> >     {
> >         *(int*)pi = 1;
> >     }
> >     </foo3.c>
> > 
> >     <main3.c>
> >     #include <stdio.h>
> >     void foo3(const int* pi);
> >     int main(void)
> >     {
> >         const int i = 0;
> >         foo3(&i);
> >         printf("i = %d\n", i);
> >         return 0;
> >     }
> >     </main3.c>
> > 
> > </Program3>
> > 
> > Program3 defines 'i' const, and attempts to modify it through a const pointer, by casting const away in foo3().
> > 
> > On my particular system, when compiling Program3 with gcc 4.4.7 with optimizations turned off (-O0), the program prints "i = 1". With optimizations turned on (-O3), it prints "i = 0".
> > 
> > The question of which of these two behaviors is "correct" would be pointless, since Program3 has undefined behavior.
> > 
> > 
> > Antoine
> > --
> 
> 
> -- 
> Chen Gang
> 
> Flying Transformer

> begin:vcard
> fn:Chen Gang
> n:;Chen Gang
> version:2.1
> end:vcard
> 


  reply	other threads:[~2013-01-13 17:41 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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
     [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
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
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=20130113174105.GA24081@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=antoine.trux@gmail.com \
    --cc=chen.gang.flying.transformer@gmail.com \
    --cc=clameter@sgi.com \
    --cc=fa.linux.kernel@googlegroups.com \
    --cc=hannes@saeurebad.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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

Powered by JetHome