[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200801181155.22301.vlobanov@speakeasy.net>
Date: Fri, 18 Jan 2008 11:55:22 -0800
From: Vadim Lobanov <vlobanov@...akeasy.net>
To: Zan Lynx <zlynx@....org>
Cc: Andy Lutomirski <luto@...ealbox.com>, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Schwartz <davids@...master.com>,
Johannes Weiner <hannes@...urebad.de>, clameter@....com,
penberg@...helsinki.fi
Subject: Re: Why is the kfree() argument const?
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 function calls, before it cannot assume that
> > the two functions (in their internal implementations) do not touch some
> > other, unknown to this code, global variable.
>
> This is why GCC has the pure and const function attributes. These
> attributes are more powerful than the "const" keyword, and do allow
> optimizations with assumptions about global state.
Oh, absolutely. The problem, however, is that very very few people actually
use these function attributes in their code. Heck, we don't even use the
standard restrict keyword, much less gcc-specific function annotations.
I think that one part of the problem is because gcc seems to have had
attribute diarrhea -- I know of noone who can recite more than 10% of the
available attributes without glancing at the documentation. The other part of
the problem is that gcc does no sanity checks on the provided attributes. For
example, the code below compiles perfectly fine without a peep, even
with -Wall and -Wextra.
int global;
void foobar(const int *x) __attribute__((const));
void foobar(const int *x)
{
if (*x)
*(int *)x = 7;
global = 11;
}
*grumble, grumble* :-)
-- Vadim Lobanov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists