If you have ever worked on another free software Python project, you are
probably already familiar with it.
-We try to stay compatible with Python 2.4, so please don't rely on any
-features that were introduced later, such as the "with" statement.
-
But to save you the trouble of reading the Linux kernel style guide, here
are the highlights.
int ret = 0;
if (y < 10) {
- z = malloc(sizeof(int)*y);
- if (!z) {
+ z = malloc(sizeof(int) * y);
+ if (z == NULL) {
ret = 1;
goto done;
}
print("Allocated %d elements.\n", y);
done:
- if (z) {
+ if (z != NULL) {
free(z);
}
}
-Checking Pointer Values
------------------------
-
-When invoking functions that return pointer values, either of the following
-are acceptable. Use your best judgement and choose the more readable option.
-Remember that many other persons will review it:
-
- if ((x = malloc(sizeof(short)*10)) == NULL ) {
- fprintf(stderr, "Unable to alloc memory!\n");
- }
-
-or:
-
- x = malloc(sizeof(short)*10);
- if (!x) {
- fprintf(stderr, "Unable to alloc memory!\n");
- }
-
-
Primitive Data Types
--------------------
"struct x { .. };". We know there are still such typedefs in the code,
but for new code, please don't do that anymore.
+Initialize pointers
+-------------------
+
+All pointer variables MUST be initialized to NULL. History has
+demonstrated that uninitialized pointer variables have lead to various
+bugs and security issues.
+
+Pointers MUST be initialized even if the assignment directly follows
+the declaration, like pointer2 in the example below, because the
+instructions sequence may change over time.
+
+Good Example:
+
+ char *pointer1 = NULL;
+ char *pointer2 = NULL;
+
+ pointer2 = some_func2();
+
+ ...
+
+ pointer1 = some_func1();
+
+Bad Example:
+
+ char *pointer1;
+ char *pointer2;
+
+ pointer2 = some_func2();
+
+ ...
+
+ pointer1 = some_func1();
+
Make use of helper variables
----------------------------
Good Example:
- char *name;
+ char *name = NULL;
name = get_some_name();
if (name == NULL) {
ret = some_function_my_name(get_some_name());
...
+Please try to avoid passing function return values to if- or
+while-conditions. The reason for this is better handling of code under a
+debugger.
+
+Good example:
+
+ x = malloc(sizeof(short)*10);
+ if (x == NULL) {
+ fprintf(stderr, "Unable to alloc memory!\n");
+ }
+
+Bad example:
+
+ if ((x = malloc(sizeof(short)*10)) == NULL ) {
+ fprintf(stderr, "Unable to alloc memory!\n");
+ }
+
+There are exceptions to this rule. One example is walking a data structure in
+an iterator style:
+
+ while ((opt = poptGetNextOpt(pc)) != -1) {
+ ... do something with opt ...
+ }
+
+But in general, please try to avoid this pattern.
+
+
Control-Flow changing macros
----------------------------
like CHECK_STATUS, CHECK_VAL and others.
-Function names in DEBUG statements
-----------------------------------
+DEBUG statements
+----------------
-Many DEBUG statements contain the name of the function they appear in. This is
-not a good idea, as this is prone to bitrot. Function names change, code
-moves, but the DEBUG statements are not adapted. Use %s and __func__ for this:
+Use these following macros instead of DEBUG:
-Bad Example:
- DEBUG(0, ("strstr_m: src malloc fail\n"));
+DBG_ERR log level 0 error conditions
+DBG_WARNING log level 1 warning conditions
+DBG_NOTICE log level 3 normal, but significant, condition
+DBG_INFO log level 5 informational message
+DBG_DEBUG log level 10 debug-level message
-Good Example:
- DEBUG(0, ("%s: src malloc fail\n", __func__));
+Example usage:
+
+DBG_ERR("Memory allocation failed\n");
+DBG_DEBUG("Received %d bytes\n", count);
+
+The messages from these macros are automatically prefixed with the
+function name.