Re: Why is the kfree() argument const?
From: Andy Lutomirski
Date: Fri Jan 18 2008 - 08:54:32 EST
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 introduced in part to provide greater control over optimization. Several
important optimization techniques are based on the principle of "cacheing": under certain
circumstances the compiler can remember the last value accessed (read or written) from a
location, and use this retained value the next time that location is read. (The memory, or
"cache", is typically a hardware register.) If this memory is a machine register, for instance, the
code can be smaller and faster using the register rather than accessing external memory.
The basic qualifiers can be characterized by the restrictions they impose on access and
cacheing:
const No writes through this lvalue. In the absence of this qualifier, writes may occur
through this lvalue.
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);
especially if it can prove that the pointer to x doesn't otherwise
escape or that foo doesn't call anything that could see the pointer (and
given that gcc has special magical markings for malloc, one way this
could be "proven" is to have x be some freshly malloced object.
If foo is kfree, then the above transformation is clearly invalid.
(Note that this isn't just a problem for optimizers -- a programmer
might expect that passing a pointer to a function that takes a const
pointer argument does not, in and of itself, change the pointed-to
value. Given that const certainly does not mean that no one else
changes the object, I'm not sure what else it could mean. kfree does
not have either property, so I'm don't think it makes sense for it to
take a const argument.)
--Andy
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.
restrict Objects referenced through a restrict-qualified pointer have a special
association with that pointer. All references to that object must directly or
indirectly use the value of this pointer. In the absence of this qualifier, other
pointers can alias this object. Cacheing the value in an object designated through
a restrict-qualified pointer is safe at the beginning of the block in which the
pointer is declared, because no pre-existing aliases may also be used to reference
that object. The cached value must be restored to the object by the end of the
block, where pre-existing aliases again become available. New aliases may be
formed within the block, but these must all depend on the value of the
restrict-qualified pointer, so that they can be identified and adjusted to refer
to the cached value. For a restrict-qualified pointer at file scope, the block
is the body of main.
ciao
cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/