Re: [RFC] bloody mess with __attribute__() syntax

[Al Viro <viro@ftp.linux.org.uk>]

On Fri, Jul 06, 2007 at 01:33:30AM -0700, Josh Triplett wrote:
> Al Viro wrote:
> > On Thu, Jul 05, 2007 at 11:50:56AM -0700, Josh Triplett wrote:
> >  
> >> No, I mean __attribute__((context(...))), which means something
> >> different.  __context__() works as a statement statement changing the
> >> context.  __attribute__((context(...))) works as an attribute modifying
> >> a type to say that it requires a given context, and that
> >> accessing/calling it changes the context.  Somewhat of an odd
> >> distinction, but sparse currently works that way.
> >  
> > That's actually not a qualifier from the syntax point of view...
> > It makes sense *only* on function types - we simply ignore it
> > on anything else.
> 
> For now, yes.  I intend to make use of the context attribute on arbitrary
> pointers or data.  For example, I want to specify that you must hold a given
> lock in order to access a structure field, and enforce that context when you
> access the field.

What kind of annotations on functions do you expect to need for that
enforcing?
 
> For functions, yes.  In the case of pointers or data, I do want the context
> attribute to work like a qualifier: you might want to apply it to a pointer,
> or to the pointer target, or to a structure field, or an entire structure...

I'm not sure I like the idea of having the same qualifier mean very
different things on functions and data objects ["gets locks" vs. "needs
locks"]...
 
> If foo requires context x, and bar requires context y, then (n ? foo : bar)();
> *might* require context x and *might* require context y.

... the hell?  On functions it's not about "requires", it's about "changes".

> See above.  Eventually we might have advanced dataflow analysis deriving
> attributes for us; for now, function pointers will need explicit contexts.

How do you compare two contexts for equality?

> Currently ignored, yes.  I certainly hope that providing a context expression
> proves sufficient to specify a context.  Yes, problems arise if you need to do
> complex unification of context expressions, but I *think* that we can handle
> the simpler cases first and the complicated cases as needed.  If you have any
> suggestions that might improve context checking, I'd love to discuss them with
> you.

What do you call simpler cases?  A constant being a context expression?