Re: Why is the kfree() argument const?

[Vadim Lobanov <vlobanov@speakeasy.net>]

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