On Thu, Jul 05, 2007 at 01:56:35PM -0700, Linus Torvalds wrote:
> 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
On Thu, 2007-07-05 at 21:08 +0100, Al Viro wrote:
> 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 __
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
wh
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?
.
On Thu, 2007-07-05 at 20:13 +0100, Al Viro wrote:
> On Thu, Jul 05, 2007 at 11:50:56AM -0700, Josh Triplett wrote:
> > On Thu, 2007-07-05 at 17:43 +0100, Al Viro wrote:
> > > On Thu, Jul 05, 2007 at 08:36:35AM -0700, Josh Triplett wrote:
> > > > Wow. Insane. So these all declare the same type:
>
On Thu, Jul 05, 2007 at 11:50:56AM -0700, Josh Triplett wrote:
> On Thu, 2007-07-05 at 17:43 +0100, Al Viro wrote:
> > On Thu, Jul 05, 2007 at 08:36:35AM -0700, Josh Triplett wrote:
> > > Wow. Insane. So these all declare the same type:
> > > __attribute__((foo)) T *v;
> > > T __attribute__((foo)
On Thu, 2007-07-05 at 17:43 +0100, Al Viro wrote:
> On Thu, Jul 05, 2007 at 08:36:35AM -0700, Josh Triplett wrote:
> > Wow. Insane. So these all declare the same type:
> > __attribute__((foo)) T *v;
> > T __attribute__((foo)) *v;
> > T *__attribute__((foo)) v;
> > ? Specifically, they point to a
On Thu, 5 Jul 2007, Al Viro wrote:
>
> I.e. you get per-attribute rules (fsckloads of them) and no way to tell
> what do the attributes apply to unless you know the rules for given attribute.
It basically boils down to "__attribute__((x))" is basically a _single_
keyword.
There is no "__attri
On Thu, Jul 05, 2007 at 10:26:40AM -0700, Linus Torvalds wrote:
> And I'm just saying that:
> (a) having two different magic keywords is silly and stupid, since:
> (b) We already have *one* magic keyword that can (and has to) look at its
> subwords, and those sub-words have the capability t
On Thu, 5 Jul 2007, Al Viro wrote:
On Thu, Jul 05, 2007 at 09:41:55AM -0700, Linus Torvalds wrote:
Note that gcc rules for __attribute__() (and that's the only source
of rules we _have_ for the damn thing) clearly say that
int __user *p;
is the same thing as
int *__user p;
Quic
On Thu, Jul 05, 2007 at 09:41:55AM -0700, Linus Torvalds wrote:
> IOW, as far as I can tell, there's really no reason to add a
> "__qualifier__" handler, because it's not going to help us. Anything we
> can do with __qualifier__, we can already do with our __attribute__
> parsing: what you sugge
On Thu, Jul 05, 2007 at 09:41:55AM -0700, Linus Torvalds wrote:
> > Note that gcc rules for __attribute__() (and that's the only source
> > of rules we _have_ for the damn thing) clearly say that
> > int __user *p;
> > is the same thing as
> > int *__user p;
>
> Quick question: is there so
On Thu, Jul 05, 2007 at 08:36:35AM -0700, Josh Triplett wrote:
> Wow. Insane. So these all declare the same type:
> __attribute__((foo)) T *v;
> T __attribute__((foo)) *v;
> T *__attribute__((foo)) v;
> ? Specifically, they point to a foo-T, for convenient shooting?
They all give you foo-pointe
On Thu, 5 Jul 2007, Al Viro wrote:
>
> Now, that idiocy would be none of our concern, if not for the fact
> that noderef and address_space() are definitely supposed to imitate
> qualifiers.
Absolutely.
> Note that gcc rules for __attribute__() (and that's the only source
> of rules we _have_ f
On Thu, Jul 05, 2007 at 02:52:22PM +0200, Ulrich Weigand wrote:
> The Named Address Space extension is documented in chapter 5 of
> Technical Report 18037:
> ISO/IEC JTC1 SC22 WG14 N1169
> "Programming languages - C - Extensions to support embedded processors"
> http://www.open-std.org/jtc1/s
Al Viro wrote:
> We have a fun problem and for a change it's not sparse fault.
> It's gcc folks' one. Basically, __attribute__((...)) behaves in
> an idiotic way and it's an intentional (and documented) behaviour.
> In declaration of form
> T __attribute__((foo)) **v;
> the attribute a
On Thursday 05 July 2007, Al Viro wrote:
> Frankly, I would rather add a new primitive (__qualifier__) mirroring the
> __attribute__, but acting like real qualifiers do. And switched the
> noderef et.al. to it. The only real alternative is to have __attribute__
> behaviour dependent on its guts a
17 matches
Mail list logo
