math: delete old unused code
[smatch.git] / Documentation / sparse.txt
blob061791eb5e548e38d671379af72ee67cdc9b7676
1 Sparse
2 ~~~~~~
4 __nocast vs __bitwise:
6 __nocast warns about explicit or implicit casting to different types.
8 HOWEVER, it doesn't consider two 32-bit integers to be different
9 types, so a __nocast 'int' type may be returned as a regular 'int'
10 type and then the __nocast is lost.
12 So "__nocast" on integer types is usually not that powerful. It just
13 gets lost too easily. It's more useful for things like pointers. It
14 also doesn't warn about the mixing: you can add integers to __nocast
15 integer types, and it's not really considered anything wrong.
17 __bitwise ends up being a "stronger integer separation". That one
18 doesn't allow you to mix with non-bitwise integers, so now it's much
19 harder to lose the type by mistake.
21 So the basic rule is:
23  - "__nocast" on its own tends to be more useful for *big* integers
24 that still need to act like integers, but you want to make it much
25 less likely that they get truncated by mistake. So a 64-bit integer
26 that you don't want to mistakenly/silently be returned as "int", for
27 example. But they mix well with random integer types, so you can add
28 to them etc without using anything special. However, that mixing also
29 means that the __nocast really gets lost fairly easily.
31  - "__bitwise" is for *unique types* that cannot be mixed with other
32 types, and that you'd never want to just use as a random integer (the
33 integer 0 is special, though, and gets silently accepted iirc - it's
34 kind of like "NULL" for pointers). So "gfp_t" or the "safe endianness"
35 types would be __bitwise: you can only operate on them by doing
36 specific operations that know about *that* particular type.
38 Generally, you want __bitwise if you are looking for type safety.
39 "__nocast" really is pretty weak.
41 Reference:
43 * Linus' e-mail about __nocast vs __bitwise:
45   http://article.gmane.org/gmane.linux.kernel.mm/75784