Andriy,
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.
You still have to deal with the fact that at some point sometype_t
objects have to interact with other objects. This can be surprisingly
fiddly. I don't have any experience of just doing this for purely
API related issues, but doing it for types in general is very hard
because developers have to learn to think in a completely different way.
Given:
int f(int a);
int g(sometype_t b);
sometype_t x, y;
int z;
...
z = x; // what do you want to do about this?
Flag this too.
But adding a cast to (int) would make it ok?
Any cases I missed?
The list looks pretty exhaustive.
Let me think more, though.
What about passing arguments to functions defined in
system headers (ie those included via <> rather than "")?
Would you treat these as special and not require explicit
casts away from sometype_t?
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!
--
Derek M. Jones tel: +44 (0) 1252 520 667
Knowledge Software Ltd mailto:[email protected]
Source code analysis http://www.knosof.co.uk
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
