于 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
于 2013年01月14日 04:54, Cong Ding 写道:
> On Sun, Jan 13, 2013 at 9:10 AM, Chen Gang F T
> 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
On Sun, Jan 13, 2013 at 9:10 AM, 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 c
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 sai
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 togethe
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
excer
"J.A. Magallón" <[EMAIL PROTECTED]> writes:
> That's what __attribute__ ((pure)) is for, but if none of the
> functions is pure, the compiler can not be sure about side effects
> and can not reorder things. Don't forget that functions can do
> anything apart from mangling with their arguments.
Th
On Fri, 18 Jan 2008 18:24:29 +0100, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> 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);
>
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Nonsense. The 'kfree' function *destroys* the object pointer to by the
> > pointer. How can you describe that as not doing anything to the object?
>
> Here's an idea. Think it through.
>
> Why don't we need write permissions to a file to unlink it?
On Friday 18 January 2008 11:31:05 am Zan Lynx wrote:
> On Fri, 2008-01-18 at 11:14 -0800, Vadim Lobanov wrote:
> > Second, even if const did have stronger semantics that forbade the value
> > of x from being modified during execution of foo, the compiler still
> > could not reorder the two functio
On Fri, 2008-01-18 at 11:14 -0800, Vadim Lobanov wrote:
[cut]
> Second, even if const did have stronger semantics that forbade the value of x
> from being modified during execution of foo, the compiler still could not
> reorder the two function calls, before it cannot assume that the two
> func
On Friday 18 January 2008 05:54:12 am Andy Lutomirski wrote:
> 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);
>
> especially if it can prove that the pointer to x doesn't
Olivier Galibert wrote:
> On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] 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 Friday 18 January 2008 03:47:01 am Giacomo A. Catenazzi wrote:
> Changing the name of variables in your example:
>
> extern print_int(const int *);
>
> int main(int argc, char **argv)
> {
>extern int errno;
>
>errno = 0;
>print_int(&i);
>return errno;
> }
Except that changing in
On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] 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 attribut
On Jan 18, 2008 6:02 AM, David Schwartz <[EMAIL PROTECTED]> wrote:
>
> However, *destroying* an object is not a metadata operation -- it destroys
> the data as well. This is kind of a philosophical point, but an object does
> not have a "does this object exist" piece of metadata. If an object does
On Thu, Jan 17, 2008 at 09:02:44PM -0800, David Schwartz wrote:
> 3) It is most useful for 'kfree' to be non-const because destroying an
> object through a const pointer can easily be done in error. One of the
> reasons you provide a const pointer is because you need the function you
> pass the poi
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
Giacomo A. Catenazzi wrote :
> [EMAIL PROTECTED] 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
On Thu, 17 Jan 2008, David Schwartz wrote:
>
> Nonsense. The 'kfree' function *destroys* the object pointer to by the
> pointer. How can you describe that as not doing anything to the object?
Here's an idea. Think it through.
Why don't we need write permissions to a file to unlink it?
Here's
David Schwartz wrote:
2) The 'kfree' operation changes the logical state of the object pointed to,
as the object goes from existent to non-existent.
I don't think that kfree() itself changes the state of the object. It
doesn't call a destructor or anything like that, so the object itself
mu
[EMAIL PROTECTED] 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 assumption
On Fri, Jan 18, 2008 at 02:31:16PM +0100, Björn Steinbrink wrote:
...
>
> Do you see anything that casts the const away? No? Me neither. Still,
> the memory that p points to was changed, because there was another
> pointer and that was not const.
*another* being key here.
>
> > *That* is the pu
On Fri, Jan 18, 2008 at 12:47:01PM +0100, Giacomo A. Catenazzi wrote:
...
> "restrict" exists for this reason. const is only about lvalue.
You think that I try to put more meaning into const than I do - but I don't.
Please read what I wrote, not what you want to think I wrote.
I agree that if I
Giacomo Catenazzi wrote:
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were introdu
Giacomo Catenazzi wrote:
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were introdu
On 2008.01.18 10:48:26 +0100, Jakob Oestergaard wrote:
> On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
> ...
> > Why do you make that mistake, when it is PROVABLY NOT TRUE!
> >
> > Try this trivial program:
> >
> > int main(int argc, char **argv)
> > {
> > in
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,
Jakob Oestergaard wrote:
On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
...
Why do you make that mistake, when it is PROVABLY NOT TRUE!
Try this trivial program:
int main(int argc, char **argv)
{
int i;
const int *c;
On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
...
> Why do you make that mistake, when it is PROVABLY NOT TRUE!
>
> Try this trivial program:
>
> int main(int argc, char **argv)
> {
> int i;
> const int *c;
>
> i = 5;
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
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were introduced in part to provide grea
Linus Torvalds wrote:
>
> On Thu, 17 Jan 2008, David Schwartz wrote:
>>> "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.
>
> So why do you compl
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > > "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.
> So why do you complai
On Thu, 17 Jan 2008, David Schwartz wrote:
>
> > "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.
So why do you complain?
kfree() literally
> 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 l
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.
"
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Which does change the thing the pointer points to. It goes from being a
> > valid object to not existing.
> No. It's the *pointer* that is no longer valid.
The pointer is no longer valid because the object it pointed to no longer
exists. The poi
On Thu, 17 Jan 2008, David Schwartz wrote:
>
> Which does change the thing the pointer points to. It goes from being a
> valid object to not existing.
No. It's the *pointer* that is no longer valid.
There's definitely a difference between "exists and is changed" and
"doesn't exist any more".
On Wed, 16 Jan 2008, Christoph Lameter wrote:
>
> Correct and we have gcc 4.2 currently spitting out warnings because of
> casting to non const. Any idea how to convince gcc that this is okay?
Either don't use a broken compiler (casting a const pointer to a non-const
is definitely not a bug),
On Wed, 16 Jan 2008, Johannes Weiner wrote:
>
> Okay, I understood that now. A const qualifier just forbids modifying
> the underlying memory _through this particular pointer_, right?
Yes, exactly.
> In the case of slub's kfree(), which takes a const pointer, you pass it
> on to slab_free() w
Hi,
Christoph Lameter <[EMAIL PROTECTED]> writes:
> On Wed, 16 Jan 2008, Johannes Weiner wrote:
>
>> So if I got it right and you actually modify the memory you only got a
>> const pointer to, you reach a level where you _have to_ break this
>> policy and cast to a non-const pointer, as it is cur
Hi,
Christoph Lameter <[EMAIL PROTECTED]> writes:
> On Wed, 16 Jan 2008, Johannes Weiner wrote:
>
>> So if I got it right and you actually modify the memory you only got a
>> const pointer to, you reach a level where you _have to_ break this
>> policy and cast to a non-const pointer, as it is cur
On Wed, Jan 16, 2008 at 10:39:00AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 16 Jan 2008, Johannes Weiner wrote:
> >
> > is there any reason why kfree() takes a const pointer just to degrade it
> > with the call to slab_free()/__cache_free() again? The promise that the
> > pointee is not modif
On Wed, 16 Jan 2008, Johannes Weiner wrote:
> So if I got it right and you actually modify the memory you only got a
> const pointer to, you reach a level where you _have to_ break this
> policy and cast to a non-const pointer, as it is currently done in
> kfree(). No?
Correct and we have gcc 4.
Hi,
Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> "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.
[...]
> - From a very obvious and
On Wed, 16 Jan 2008, Johannes Weiner wrote:
>
> is there any reason why kfree() takes a const pointer just to degrade it
> with the call to slab_free()/__cache_free() again? The promise that the
> pointee is not modified is just bogus in this case, anyway, isn't it?
"const" has *never* been ab
Hi,
On Wed, 16 Jan 2008, Johannes Weiner wrote:
> > is there any reason why kfree() takes a const pointer just to degrade it
> > with the call to slab_free()/__cache_free() again? The promise that the
> > pointee is not modified is just bogus in this case, anyway, isn't it?
On Wed, 16 Jan 2008,
On Mit, 2008-01-16 at 08:48 -0800, Christoph Lameter wrote:
> On Wed, 16 Jan 2008, Johannes Weiner wrote:
>
> > is there any reason why kfree() takes a const pointer just to degrade it
> > with the call to slab_free()/__cache_free() again? The promise that the
> > pointee is not modified is just
On Wed, 16 Jan 2008, Johannes Weiner wrote:
> is there any reason why kfree() takes a const pointer just to degrade it
> with the call to slab_free()/__cache_free() again? The promise that the
> pointee is not modified is just bogus in this case, anyway, isn't it?
The object is modified in vario
Hi,
is there any reason why kfree() takes a const pointer just to degrade it
with the call to slab_free()/__cache_free() again? The promise that the
pointee is not modified is just bogus in this case, anyway, isn't it?
Hannes
--
To unsubscribe from this list: send the line "unsubscribe l
51 matches
Mail list logo
