On Mon, 31 Jan 2011, SF Markus Elfring wrote: > >> A query for the function return type would be only useful if I > >> would try to construct a variable assignment or object initialisation > >> as a potential repair. Otherwise: I would need more introspection > >> capabilities to take special function properties into account. > >> Example: Was the affected function implementation called from within a > >> signal handler call hierarchy? Does my "fix" need to be > >> "async-signal-safe"? > > > > I don't think the function type will tell you the whole story even without > > these considerations. For example, if the return type is int, then 0 > > might indicate failure, or some negative constant might indicate failure, > > or both (cf OpenSSL), depending on the coding conventions. > > I imagine that this situation can be handled by a function name library > together > with corresponding predicate functions. > Some of the involved details were already mentioned in a discussion on the > topic > "Support for error handling by aspect-oriented programming". > http://aosd.net/pipermail/discuss_aosd.net/2007-April/002136.html
The function name library sounds like what is implemented in iteration.cocci. It collects the function that return ERR_PTR, and then one can do what one wants with that information. julia _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
