lkml.org 
[lkml]   [2007]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] bloody mess with __attribute__() syntax


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

\
 
 \ /
  Last update: 2007-07-05 22:59    [W:0.186 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site