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

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

On Fri, Jul 06, 2007 at 12:29:27PM -0700, Josh Triplett wrote:
> The existing context annotations should suffice for many cases.
> compiler.h will need new wrappers for cases like requiring a lock.  For
> a very simple example:
> 
> compiler.h:
> #define require_context(x) __attribute__((context(x,1,1))
> 
> magic_device.c:
> DEFINE_SPINLOCK(device_lock);
> struct the_device the_device require_context(device_lock);

*ugh*

More ugly syntax...

> compiler.h:
> #ifdef __CHECKER__
> #define fake_context(x) extern const int x
> #else
> #define fake_context(x)
> #endif
> 
> preempt.h:
> fake_context(preemption);
> #define preempt_disable() ... __acquire(preemption)
> #define preempt_enable() ... __release(preemption)
> #define might_sleep_attr() ... /* something */
 
Still not expressive enough...  Consider e.g.

struct foo *lookup_foo(char *s); // lookup by name, return NULL if failed
				 // or pointer to struct foo with ->mutex
				 // held.  Caller should unlock.

It's legitimate, not particulary rare and AFAICS can't be expressed.

> Sparse does not yet enforce all of these conditions.  Also, the "at
> least this value" semantic for the precondition makes it hard to use
> contexts for things like "this blocks" and "may not block in this
> context".  As I said, it needs work.  However, I intend for it to mean
> *exactly* the same thing on functions or variables, except that in the
> former case it means "when called", and in the latter case it means
> "when accessed".  In both cases, you can require a context and change
> the context.

_What_ change in case of objects?

> A fine question.  In the simple cases, "same symbol" will work fairly
> well; certainly better than the current "always equal" comparison. :)
> Ideally, however, you want "refers to the same value".  Alias analysis
> could do a fairly good job of that, I think.

Not particulary useful, since for
	int foo(struct bar *p) __acquires(&p->lock);
	int bar(struct bar *p) __acquires(&p->lock);
you will get false negative in (n ? foo : bar) *and* it will persist even if
you go for
	int foo(struct bar *p) __acquires(p);
	int bar(struct bar *p) __acquires(p);
since you will have different symbols (same name, different scopes) here.