[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070705200839.GR21478@ftp.linux.org.uk>
Date: Thu, 5 Jul 2007 21:08:39 +0100
From: Al Viro <viro@....linux.org.uk>
To: Josh Triplett <josht@...ux.vnet.ibm.com>
Cc: Josh Triplett <josh@...edesktop.org>, linux-sparse@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] bloody mess with __attribute__() syntax
On Thu, Jul 05, 2007 at 12:35:53PM -0700, Josh Triplett wrote:
> OK, that seems inconsistent with what you said before. You said that
> T __attribute__((foo)) *v;
... in gcc.
> gives you a foo-pointer-to-T. So shouldn't
> int __attribute__((noderef)) *v;
> give you a noderef-pointer-to-int?
... if we followed gcc rules.
> However, noderef seems like a property of a pointer, hence why I
> proposed the example I did. A warning should occur when you do
> *(<noderef T *>v) to get a T, not when you do *(<* noderef T>v) to get a
> noderef T.
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 *.
Semantics of noderef is simple: you should not access or modify the value
of noderef object. That's all. int __noderef * is an absolutely normal
pointer to such object. Think of __noderef as of a stronger variant of const.
It's just another qualifier, with usual qualifier syntax. It can occur
in the same places where const can, giving the same kind of effect on type.
See 6.7.5.1 and 6.7.3 for general stuff on qualifiers...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists