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