diff --git a/README.md b/README.md
index f69d8c8b..6df362e1 100644
--- a/README.md
+++ b/README.md
@@ -265,12 +265,6 @@ You may not use the internal fields of the structure.
 Internal fields of the structure are subject to change even for small revision
 of the library.
 
-When using M\*LIB, sometimes (often) the list of errors/warnings generated by the compiler can be (very) huge (specially with latest compilers),
-even if the error itself is minor. This is more or less the same as the use of template in C++.
-You should focus mainly on the first reported error/warning
-even if the link between what the compiler said and what the error is is not immediate:
-for example, a lack of inclusion of an header, an unknown oplist, a missing argument, a missing method in an oplist, ... Another way to debug is to generate the preprocessed file (by usually calling the compiler with the '-E' option instead of '-c') and check what's wrong in the preprocessed file.
-
 The final goal of the library is to be able to write code like this in pure C while keeping type safety and compile time name resolution:
 
 	let(list, list_uint_t) {
@@ -282,6 +276,33 @@ The final goal of the library is to be able to write code like this in pure C wh
 	}
 
 
+ERRORS & COMPILERS
+------------------
+
+When using M\*LIB, sometimes (often) the list of errors/warnings generated
+by the compiler can be (very) huge (specially with latest compilers),
+even if the error itself is minor. This is more or less the same as the use of template in C++.
+You should focus mainly on the first reported error/warning
+even if the link between what the compiler report and what the error is
+is not immediate. Examples of typical errors:
+
+* lack of inclusion of an header,
+* overiding localy operator names by macros (like NEW, DEL, INIT, OPLIST, ...),
+* lack of ( ) or double level of ( ) around the oplist,
+* an unknown variable (example using DEFAULT\_OPLIST instead of M\_DEFAULT\_OPLIST),
+* a missing argument,
+* a missing mandatory operator in the oplist.
+
+Another way to debug is to generate the preprocessed file
+(by usually calling the compiler with the '-E' option instead of '-c')
+and check what's wrong in the preprocessed file.
+
+If there is a warning reported by the compiler in the generated code,
+then there is definitly an **error** you should fix (except if it reports
+shadowed variables).
+
+
+
 OPLIST
 ------