on 12/11/2010 16:34 Derek M Jones said the following: > Andriy > >> I wonder if coccinelle can help me with the following issue. >> There is a type, let's call it sometype_t, that is typedef-ed to int. > > I have spent a lot of time looking at this issue from a static analysis > point of view. > > The two most common cases are: > > 1) sometype_t should be treated as a type that is not compatible with > any other type. I don't think you want to do this?
Actually, I probably would want to do that, because it's possible that in future it would grow beyond what can be provided by aliasing to a fundamental integer type. So, at the moment, I would like to keep the benefits of it being a simple integer type, but in the future sometype_t may be handled only by specialized functions. > 2) the type of sometype_t could change in the future and the code > should not contain any implicit dependencies on the type it currently > has (this occurs frequently with size_t). Yes, definitely, given the above future possibilities. > Given: > > int f(int a); > int g(sometype_t b); > sometype_t x, y; > int z; > > x = z; // you want to flag this? Yes. > x = (sometype_t)z; // is this ok? Yes, for time being. > z = x; // what do you want to do about this? Flag this too. > x = 0; // a common case, do you really want to flag this? > // Requiring people add a cast will make you unpopular. Probably we can keep initializations with constants as it can be easily found in the future if the need will arise. > x = y + z; // arithmetic conversion probably makes this work ok > ...x ? y : z ... // the biggest smoking gun > x = (int)y; // or perhaps this one is > > if (x < z) ; // is a relational op equivalent to assignment? > if (x == y) ; // equality ops are usually treated as equivalent > > g(any_of_the_above_rhs_assignment_expression); // treat same as assignment? > f(x); // flag f as having the 'wrong' parameter type? Want to flag all of the above cases. > Any cases I missed? The list looks pretty exhaustive. Let me think more, though. Thanks! >> There is an API which uses that type consistently to provide for possible >> future >> extensions. But that there are many lax users of that API which frequently >> use >> int instead of sometype_t. >> For example, sometimes a sometype_t variable is assigned with int value, or >> conversely a sometype_t value is assigned to int variable, or int value is >> passed >> in a function parameter where sometype_t is expected. >> >> I wonder if I could use the power of coccinelle to easily find and perhaps >> even >> fix such lax type handling. >> >> Thanks! > -- Andriy Gapon _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
