antoine.trux | 12 Jan 20:18 2013
Picon

Re: Why is the kfree() argument const?

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>
(Continue reading)

Chen Gang F T | 13 Jan 09:10 2013
Picon

Re: Why is the kfree() argument const?

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 *).

于 2013年01月13日 03:18, antoine.trux <at> 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 
(Continue reading)

Guenter Roeck | 13 Jan 18:41 2013
Picon

Re: Why is the kfree() argument const?

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 <at> gmail.com 写道:
> > On Wednesday, January 16, 2008 8:39:48 PM UTC+2, Linus Torvalds wrote:
(Continue reading)

Chen Gang F T | 14 Jan 02:45 2013
Picon

Re: Why is the kfree() argument const?

于 2013年01月14日 01:41, Guenter Roeck 写道:
> 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;

  Maybe.

  :-)

--

-- 
Chen Gang

Flying Transformer
Cong Ding | 13 Jan 21:54 2013
Picon

Re: Why is the kfree() argument const?

On Sun, Jan 13, 2013 at 9:10 AM, Chen Gang F T
<chen.gang.flying.transformer <at> gmail.com> 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 *).
you are definitely wrong. both of them are correct - it's the
difference between kernel space and user space.

>
> 于 2013年01月13日 03:18, antoine.trux <at> 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):
>>
(Continue reading)

Chen Gang F T | 14 Jan 02:18 2013
Picon

Re: Why is the kfree() argument const?

于 2013年01月14日 04:54, Cong Ding 写道:
> On Sun, Jan 13, 2013 at 9:10 AM, Chen Gang F T
> <chen.gang.flying.transformer <at> gmail.com> wrote:
>> >   all together:
>> >     kfree() should use 'const void *' as parameter type
>> >     the free() of C Library is incorrect (it use void *).
> you are definitely wrong. both of them are correct - it's the
> difference between kernel space and user space.
> 

  for API features, they are should be no different.

 "- From a very obvious and very *real* caller perspective, 'free()' really 
   doesn't change the thing the pointer points to. It does something 
   totally different: it makes the *pointer* itself invalid."

   "we want the types to be as tight as possible"

  so should use 'const void *' both for 'kfree()' and 'free()' .

--

-- 
Chen Gang

Flying Transformer
ecolbus | 18 Jan 13:45 2008
Picon

Re: Why is the kfree() argument const?

Giacomo Catenazzi wrote:

> const No writes through this lvalue. In the absence of this qualifier, writes may occur
> through this lvalue.
> 
> volatile No cacheing through this lvalue: each operation in the abstract semantics must
> be performed (that is, no cacheing assumptions may be made, since the location
> is not guaranteed to contain any previous value). In the absence of this qualifier,
> the contents of the designated location may be assumed to be unchanged except
> for possible aliasing.

Well, I'm still wondering if there is not something dangerous or weird about
declaring the argument of kfree() to be const... 

Since the content of the referenced object is unlikely to be declared volatile, the
compiler should be allowed to assume that its content was not changed, except
for possible aliasing. But what happens if the compiler can also prove there is 
no aliasing? In that case, he should be allowed to assume that the content
pointed to was not modified at all, right?

Consider the following code : 

struct something {
        int i;
};

...

struct something *s1, *s2;
extern int val;
(Continue reading)

Giacomo A. Catenazzi | 18 Jan 16:20 2008
Picon

Re: Why is the kfree() argument const?

ecolbus <at> voila.fr wrote:
> Giacomo Catenazzi wrote:
> 
>> const No writes through this lvalue. In the absence of this qualifier, writes may occur
>> through this lvalue.
>>
>> volatile No cacheing through this lvalue: each operation in the abstract semantics must
>> be performed (that is, no cacheing assumptions may be made, since the location
>> is not guaranteed to contain any previous value). In the absence of this qualifier,
>> the contents of the designated location may be assumed to be unchanged except
>> for possible aliasing.
> 
> Well, I'm still wondering if there is not something dangerous or weird about
> declaring the argument of kfree() to be const... 

It should be only cosmetic thing (and few warnings in some
not yet identified cases).

> Since the content of the referenced object is unlikely to be declared volatile, the
> compiler should be allowed to assume that its content was not changed, except
> for possible aliasing. But what happens if the compiler can also prove there is 
> no aliasing? In that case, he should be allowed to assume that the content
> pointed to was not modified at all, right?

I doesn't follow it. Anyway C has the "as-if" rule, which it mean:
the compiler could optimize as far the result doesn't change
(time are not issues, and result could change if a valid compiler
could give the same results).  So a very smart compiler (which
should compile all units at the same time) could do good things
without need of explicit register, static (with some exceptions),
(Continue reading)

ecolbus | 18 Jan 17:45 2008
Picon

Re: Why is the kfree() argument const?

Giacomo A. Catenazzi wrote : 
> ecolbus <at> voila.fr wrote:
> > Giacomo Catenazzi wrote:
> > 
> >> const No writes through this lvalue. In the absence of this qualifier, writes may occur
> >> through this lvalue.
> >>
> >> volatile No cacheing through this lvalue: each operation in the abstract semantics must
> >> be performed (that is, no cacheing assumptions may be made, since the location
> >> is not guaranteed to contain any previous value). In the absence of this qualifier,
> >> the contents of the designated location may be assumed to be unchanged except
> >> for possible aliasing.
> > 
> > Well, I'm still wondering if there is not something dangerous or weird about
> > declaring the argument of kfree() to be const... 
> 
> It should be only cosmetic thing (and few warnings in some
> not yet identified cases).
> 
> 
> > Since the content of the referenced object is unlikely to be declared volatile, the
> > compiler should be allowed to assume that its content was not changed, except
> > for possible aliasing. But what happens if the compiler can also prove there is 
> > no aliasing? In that case, he should be allowed to assume that the content
> > pointed to was not modified at all, right?
> 
> I doesn't follow it. Anyway C has the "as-if" rule, which it mean:
> the compiler could optimize as far the result doesn't change
> (time are not issues, and result could change if a valid compiler
> could give the same results). 
(Continue reading)

Olivier Galibert | 18 Jan 19:20 2008
Picon

Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 05:45:49PM +0100, ecolbus <at> voila.fr wrote:
> The malloc attribute is exactly about this : giving the compiler the
> indication that no other pointer aliases this object, allowing for
> better optimizations.

If you put a malloc attribute on the allocator and no free attribute
on the deallocator, you can get bugs indeed.  GIGO.

> Yes. Bad things start to happen when users add wrong indications to
> the compiler. By adding the "const" indication to kfree(), the programmer
> wrongly tells that it can optimize reading the values pointed to before or
> after calling the function (if it is also sure that they cannot be
> read/written otherwise). Current gcc implementations seem quite
> conservative in this regard, and don't optimize that much, but what about
> the future?

The future should be quite nice because:

- the compiler can not know that kmalloc does not have an alias to
  the pointer tucked somewhere accessible by other non-inline functions
  (as kfree is), especially since it does have aliases in practice, so
  it cannot prove to "not read/written otherwise" part without the
  malloc attribute

- if you add the (non-standard C) malloc attribute to kmalloc, then
  you also add the free attribute to kfree which tells the compiler
  that the pointer is invalid after the call, which ensures no
  accesses will be moved after it

  OG.
(Continue reading)

ecolbus | 18 Jan 20:10 2008
Picon

Re: Why is the kfree() argument const?


Olivier Galibert wrote:
> On Fri, Jan 18, 2008 at 05:45:49PM +0100, ecolbus <at> xxxxxxxx wrote:
> > The malloc attribute is exactly about this : giving the compiler the
> > indication that no other pointer aliases this object, allowing for
> > better optimizations.
> 
> If you put a malloc attribute on the allocator and no free attribute
> on the deallocator, you can get bugs indeed. GIGO.
> 
> 
> > Yes. Bad things start to happen when users add wrong indications to
> > the compiler. By adding the "const" indication to kfree(), the programmer
> > wrongly tells that it can optimize reading the values pointed to before or
> > after calling the function (if it is also sure that they cannot be
> > read/written otherwise). Current gcc implementations seem quite
> > conservative in this regard, and don't optimize that much, but what about
> > the future?
> 
> The future should be quite nice because:
> 
> - the compiler can not know that kmalloc does not have an alias to
> the pointer tucked somewhere accessible by other non-inline functions
> (as kfree is), especially since it does have aliases in practice, so
> it cannot prove to "not read/written otherwise" part without the
> malloc attribute
> 
> - if you add the (non-standard C) malloc attribute to kmalloc, then
> you also add the free attribute to kfree which tells the compiler
> that the pointer is invalid after the call, which ensures no
(Continue reading)


Gmane