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. > And C syntax doesn't allow qualifiers on functions - > not without creative use of typedef (which gets you in nasal demon > country - undefined behaviour). 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... [snip several function-specific issues] > Another fun question: how do we compare these suckers? Suppose > you have foo() and bar() having some kind of contexts. What contexts > do we put into n ? foo : bar and when do we allow that? If foo requires context x, and bar requires context y, then (n ? foo : bar)(); *might* require context x and *might* require context y. Similar problems arise for issues like conditional locking. So far, the solution involves saying "if it doesn't look obvious to the compiler, it doesn't look obvious to the coder, so rewrite it such that it does"; that works fairly well for Linux, though long-term I'd like to handle increasingly complex cases. In some cases, specifying more attributes helps; for instance, you can remove ambiguity by specifying context attributes on function pointers. > Similar question for p = foo; where p is a pointer to function, etc. See above. Eventually we might have advanced dataflow analysis deriving attributes for us; for now, function pointers will need explicit contexts. > I realize that the first argument of __attribute__((context(...,...,...))) > is currently ignored and pretty much hopeless as defined, but... 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. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature
