doc: fix the warnings when building the doc

It seems that Markdown is now parsed slightly differently and
now generate some warnings.

So tweak the .md files to shut up the warnings.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

2 files changed, 23 insertions, 17 deletions

diff --git a/Documentation/TODO.md b/Documentation/TODO.md
index cbda1c39..31826df3 100644
--- a/Documentation/TODO.md
+++ b/Documentation/TODO.md
@@ -32,7 +32,7 @@ Core
   ```
 
 Testsuite
---------
+---------
 * there are more than 50 failing tests. They should be fixed
   (but most are non-trivial to fix).
 
@@ -84,9 +84,13 @@ Longer term/to investigate
 * should support "-Werror=..." ?
 * All warning messages should include the option how to disable it.
   For example:
+
   	"warning: Variable length array is used."
+
   should be something like:
+
 	"warning: Variable length array is used. (-Wno-vla)"
+
 * ptrlists must have elements be removed while being iterated but this
   is hard to insure it is not done.
 * having 'struct symbol' used to represent symbols *and* types is
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`: