path: root/Documentation/process/coding-style.rst
diff options
Diffstat (limited to 'Documentation/process/coding-style.rst')
1 files changed, 34 insertions, 4 deletions
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 4e611a01adc6..8ea913e99fa1 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -938,7 +938,37 @@ result. Typical examples would be functions that return pointers; they use
NULL or the ERR_PTR mechanism to report failure.
-17) Don't re-invent the kernel macros
+17) Using bool
+The Linux kernel bool type is an alias for the C99 _Bool type. bool values can
+only evaluate to 0 or 1, and implicit or explicit conversion to bool
+automatically converts the value to true or false. When using bool types the
+!! construction is not needed, which eliminates a class of bugs.
+When working with bool values the true and false definitions should be used
+instead of 1 and 0.
+bool function return types and stack variables are always fine to use whenever
+appropriate. Use of bool is encouraged to improve readability and is often a
+better option than 'int' for storing boolean values.
+Do not use bool if cache line layout or size of the value matters, as its size
+and alignment varies based on the compiled architecture. Structures that are
+optimized for alignment and size should not use bool.
+If a structure has many true/false values, consider consolidating them into a
+bitfield with 1 bit members, or using an appropriate fixed width type, such as
+Similarly for function arguments, many true/false values can be consolidated
+into a single bitwise 'flags' argument and 'flags' can often be a more
+readable alternative if the call-sites have naked true/false constants.
+Otherwise limited use of bool in structures and arguments can improve
+18) Don't re-invent the kernel macros
The header file include/linux/kernel.h contains a number of macros that
@@ -961,7 +991,7 @@ need them. Feel free to peruse that header file to see what else is already
defined that you shouldn't reproduce in your code.
-18) Editor modelines and other cruft
+19) Editor modelines and other cruft
Some editors can interpret configuration information embedded in source files,
@@ -995,7 +1025,7 @@ own custom mode, or may have some other magic method for making indentation
work correctly.
-19) Inline assembly
+20) Inline assembly
In architecture-specific code, you may need to use inline assembly to interface
@@ -1027,7 +1057,7 @@ the next instruction in the assembly output:
: /* outputs */ : /* inputs */ : /* clobbers */);
-20) Conditional Compilation
+21) Conditional Compilation
Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c