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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
