aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Documentation/nocast-vs-bitwise.md
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/nocast-vs-bitwise.md')
-rw-r--r--Documentation/nocast-vs-bitwise.md34
1 files changed, 18 insertions, 16 deletions
diff --git a/Documentation/nocast-vs-bitwise.md b/Documentation/nocast-vs-bitwise.md
index b649abcd..9ba5a789 100644
--- a/Documentation/nocast-vs-bitwise.md
+++ b/Documentation/nocast-vs-bitwise.md
@@ -1,4 +1,5 @@
-# __nocast vs __bitwise
+__nocast vs __bitwise
+=====================
`__nocast` warns about explicit or implicit casting to different types.
HOWEVER, it doesn't consider two 32-bit integers to be different
@@ -16,25 +17,26 @@ harder to lose the type by mistake.
So the basic rule is:
- - `__nocast` on its own tends to be more useful for *big* integers
-that still need to act like integers, but you want to make it much
-less likely that they get truncated by mistake. So a 64-bit integer
-that you don't want to mistakenly/silently be returned as `int`, for
-example. But they mix well with random integer types, so you can add
-to them etc without using anything special. However, that mixing also
-means that the `__nocast` really gets lost fairly easily.
-
- - `__bitwise` is for *unique types* that cannot be mixed with other
-types, and that you'd never want to just use as a random integer (the
-integer `0` is special, though, and gets silently accepted - it's
-kind of like `NULL` for pointers). So `gfp_t` or the `safe endianness`
-types would be `__bitwise`: you can only operate on them by doing
-specific operations that know about *that* particular type.
+- `__nocast` on its own tends to be more useful for *big* integers
+ that still need to act like integers, but you want to make it much
+ less likely that they get truncated by mistake. So a 64-bit integer
+ that you don't want to mistakenly/silently be returned as `int`, for
+ example. But they mix well with random integer types, so you can add
+ to them etc without using anything special. However, that mixing also
+ means that the `__nocast` really gets lost fairly easily.
+
+- `__bitwise` is for *unique types* that cannot be mixed with other
+ types, and that you'd never want to just use as a random integer (the
+ integer `0` is special, though, and gets silently accepted - it's
+ kind of like `NULL` for pointers). So `gfp_t` or the `safe endianness`
+ types would be `__bitwise`: you can only operate on them by doing
+ specific operations that know about *that* particular type.
Generally, you want `__bitwise` if you are looking for type safety.
`__nocast` really is pretty weak.
-## Reference:
+Reference:
+----------
* Linus' e-mail about `__nocast` vs `__bitwise`: