On 26/06/15 14:53, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall <dav...@davmac.org> wrote:
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall <dav...@davmac.org> wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any other type than the
type of n itself. This value is then cast to a different pointer type. You
are mistaken if you think that the cast accesses the stored value of n. The
other "stored value" access that it occurs in that expression is to the
object pointed at by the result of the cast. [...]:
I'm sorry, I think that was phrased somewhat abrasively, which I did not
intend. Let me try this part again. If we by break up the expression in
order of evaluation:
From:
return ((const struct exec_node **)n)[0]
In order of evaluation:
n
- which accesses the stored value of n, i.e. a value of type 'struct exec
node *', via n, which is obviously of that type.
(const struct exec_node **)n
- which casts that value, after it has been retrieved, to another type. If
this were an aliasing violation, then casting any pointer variable to
another type would be an aliasing violation; this is clearly not the case.
((const struct exec_node **)n)[0]
- which de-references the result of the above cast, thereby accessing a
stored value of type 'exec node *' using a glvalue of type 'exec node *'.
I think breaking this up is a mistake, because the strict-aliasing
rules is explicitly about the *combination* of these two things.
It is not a mistake, and the strict aliasing rules are not about the
combination of these two things.
It is. In fact, it's not even possible to violate strict-aliasing
without doing at least two operations. You cannot validate operations
in a vacuum, because that's not how strict-aliasing is defined.
Any pointer dereference can violate strict aliasing - that's one
operation. If you mean that it's first necessary to construct a pointer
value in such a way that de-referencing it will be an aliasing
violation, then yes, I agree with this statement.
As I have pointed out, with your reading,
pretty much any pointer cast constitutes an aliasing violation.
No, only those violating the strict aliasing rules I posted before.
... which would only allow changing const/volatile qualifiers, not the
pointed-to type.
Your reading also disallows casting an 'int' variable to type 'long',
because that isn't on the list.
The strict aliasing rules specify what kind of reference you can use to
access an object of a particular type. They say nothing about how that
reference is obtained.
Which means that it applies regardless of how you obtain it.
Yes.
"If a program attempts to access the stored value of an object through
a glvalue of other than one of the following types the behavior is
undefined"
It says "if a *program* attempts", not "if a *statement* attempts" or
"if an *opreation* attempts". This is a whole-program deal, not
limited to one operation in isolation.
The key part of the wording is "through a glvalue":
"If a program attempts to access the stored value of an object *through
a glvalue* of other than one of the following types ..."
Going back to the original example:
return ((const struct exec_node **)n)[0]
The glvalue used to access the object in n is n itself. (I do not think
that '(const struct exec_node **)n' is even a glvalue).
You *are* accessing the underlying memory of 'n' through a different
type, and this is what strict aliasing is all about. But it takes two
steps, a single step isn't enough to do so.
I'm sorry, but your understanding is incorrect. Most pointer casts would be
illegal otherwise. And in fact most casts would be illegal. For instance:
int a;
long b = (long) a;
You reasoning says that the second line is a strict-aliasing violation,
because it access the object in 'a' which is of type 'int' via a glvalue of
type 'long'.
No, that is not in violation, because it's accessed through, and *then* casted.
Just as in '((const struct exec_node **)n)[0]', where the value of n is
accessed through n, and *then* casted.
Davin
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
