The nocast-vs-bitwise document was copied here to be sure
to remain accessible but isn't really useful here now because:
1) the original document have also been archived to lore.kernel.org
2) nocast & bitwise have now been documented
3) 2) contains a link to 1)
So, remove this redundant document.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
---
Documentation/index.rst | 1 -
Documentation/nocast-vs-bitwise.md | 43 ------------------------------
2 files changed, 44 deletions(-)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 9c76419ba5dd..cbe0521b7091 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -69,7 +69,6 @@ User documentation
:maxdepth: 1
annotations
- nocast-vs-bitwise
Developer documentation
-----------------------
diff --git a/Documentation/nocast-vs-bitwise.md b/Documentation/nocast-vs-bitwise.md
deleted file mode 100644
index 9ba5a789fc26..000000000000
--- a/Documentation/nocast-vs-bitwise.md
+++ /dev/null
@@ -1,43 +0,0 @@
-__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
-types, so a `__nocast int` type may be returned as a regular `int`
-type and then the `__nocast` is lost.
-
-So `__nocast` on integer types is usually not that powerful. It just
-gets lost too easily. It's more useful for things like pointers. It
-also doesn't warn about the mixing: you can add integers to `__nocast`
-integer types, and it's not really considered anything wrong.
-
-`__bitwise` ends up being a *stronger integer separation*. That one
-doesn't allow you to mix with non-bitwise integers, so now it's much
-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.
-
-Generally, you want `__bitwise` if you are looking for type safety.
-`__nocast` really is pretty weak.
-
-Reference:
-----------
-
-* Linus' e-mail about `__nocast` vs `__bitwise`:
-
- <https://marc.info/?l=linux-mm&m=133245421127324&w=2>
--
2.28.0
