On Thu, 5 Jul 2007, Al Viro wrote:
>
> Nope. __noderef is a property of object being pointed to. Again,
> consider &p->x. It should not be int *. And it should not be
> an error. We want it to be int __noderef *.
A more interesting example to some degree is what happens to
&*p
when p is a pointer to noderef.
The end result should be a pointer to noderef again, and it should be
legal to do (ie we didn't actually _really_ derefence it).
It's interesting for a couple of reasons, specifically it shows how sparse
ends up carrying around the "node" information in two _different_ places:
either in the SYM_NODE (or SYM_ARRAY) that actually "is" the object, _or_
in the SYM_PTR thing that describes a pointer to the object.
So this behaviour can be directly seen in the sparse type logic when we
convert to/from a pointer:
- it shows how the "pointerness" is secondary, even if we actually
do end up putting some object flags in the SYM_PTR node.
So the "*" needs to move the noderef from the SYM_PTR node into the
resulting SYM_NODE node. This is what "MOD_PTRINHERIT" is all about
(see its use in "create_pointer": it peels off the SYM_NODE'ness, but
inserts the node modifiers into the SYM_PTR).
- the address-of operator does the reverse, and we merge the information
from the pointer into the resulting node (everything but the storage
modifiers, to be exact, see "merge_type()").
So I think Josh may be confused by the fact that the SYM_PTR node actually
contains information about the thing the pointer _points_ to, and then the
SYM_NODE for the pointer object actually contains information about the
pointer itself!
So some of the flags about the object are really in the SYM_PTR node, but
despite that, they are really about the *object*, not about the pointer,
and that shows most clearly exactly when converting an object to a pointer
("&" - evaluate_addressof() and crreate_pointer()) and when dereferencing
a pointer to an object ("*" - evaluate_dereference() and merge_type())
Is it slightly complex? Yes. It's a bit strange that the SYM_PTR doesn't
contain the information about the *pointer*, and the real information
about an object is actually "one removed" from the type infromation, but
it's a rather direct result of how sparse parses and maintains the type
information.
Maybe it could have been done differently. I dunno. But it does end up
being how the C types parse most naturally, I think.
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
