>> 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 How do you think about my expectation to deal with specific function properties? > The subtle point with Coccinelle is that the code is being transformed, so > you don't want to add this error handling code if it is already there. I agree to your expectation. - That is an interesting issue for the weaving of several aspects. > In the AOP solution, they don't care (as long as they don't care about code > size or runtime overhead, depending on how the aspect weaving is implemented). I guess that software developers from this application area care about aspect conflicts. I assume that aspect weaving is an on-going research topic in computer science. > A semantic patch that takes care of the case of a function that may return > ERR_PTR(...) is shown below. Thanks for your detailed SmPL example. Regards, Markus _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
