1# __nocast vs __bitwise 2 3`__nocast` warns about explicit or implicit casting to different types. 4HOWEVER, it doesn't consider two 32-bit integers to be different 5types, so a `__nocast int` type may be returned as a regular `int` 6type and then the `__nocast` is lost. 7 8So `__nocast` on integer types is usually not that powerful. It just 9gets lost too easily. It's more useful for things like pointers. It 10also doesn't warn about the mixing: you can add integers to `__nocast` 11integer types, and it's not really considered anything wrong. 12 13`__bitwise` ends up being a *stronger integer separation*. That one 14doesn't allow you to mix with non-bitwise integers, so now it's much 15harder to lose the type by mistake. 16 17So the basic rule is: 18 19 - `__nocast` on its own tends to be more useful for *big* integers 20that still need to act like integers, but you want to make it much 21less likely that they get truncated by mistake. So a 64-bit integer 22that you don't want to mistakenly/silently be returned as `int`, for 23example. But they mix well with random integer types, so you can add 24to them etc without using anything special. However, that mixing also 25means that the `__nocast` really gets lost fairly easily. 26 27 - `__bitwise` is for *unique types* that cannot be mixed with other 28types, and that you'd never want to just use as a random integer (the 29integer `0` is special, though, and gets silently accepted - it's 30kind of like `NULL` for pointers). So `gfp_t` or the `safe endianness` 31types would be `__bitwise`: you can only operate on them by doing 32specific operations that know about *that* particular type. 33 34Generally, you want `__bitwise` if you are looking for type safety. 35`__nocast` really is pretty weak. 36 37## Reference: 38 39* Linus' e-mail about `__nocast` vs `__bitwise`: 40 41 <https://marc.info/?l=linux-mm&m=133245421127324&w=2> 42