...
}
+Functions that destroy an instance of a dynamically-allocated type
+should accept and ignore a null pointer argument. Code that calls
+such a function (including the C standard library function free())
+should omit a null-pointer check. We find that this usually makes
+code easier to read.
+
FUNCTION PROTOTYPES
common case, so this can be a real form of optimization as well.)
+RETURN VALUES
+
+ For functions that return a success or failure indication, prefer
+one of the following return value conventions:
+
+ * An "int" where 0 indicates success and a positive errno value
+ indicates a reason for failure.
+
+ * A "bool" where true indicates success and false indicates
+ failure.
+
+
MACROS
Don't define an object-like macro if an enum can be used instead.
expressions that use && and ||. Thus:
if (!isdigit((unsigned char)s[0])
- || !isdigit((unsigned char)s[1])
- || !isdigit((unsigned char)s[2])) {
+ || !isdigit((unsigned char)s[1])
+ || !isdigit((unsigned char)s[2])) {
printf("string %s does not start with 3-digit code\n", s);
}
C DIALECT
- Try to avoid using GCC extensions where possible.
-
- Some C99 extensions are OK:
+ Some C99 features are OK because they are widely implemented even in
+older compilers:
* Flexible array members (e.g. struct { int foo[]; }).
only take on the values 0 or 1, because this behavior can't be
simulated on C89 compilers.
- Don't use other C99 extensions, and especially:
-
- * Don't use // comments.
+ Don't use other C99 features that are not widely implemented in
+older compilers:
* Don't use designated initializers (e.g. don't write "struct foo
foo = {.a = 1};" or "int a[] = {[2] = 5};").
* Don't put a trailing comma in an enum declaration (e.g. don't
write "enum { x = 1, };").
+
+ As a matter of style, avoid // comments.
+
+ Avoid using GCC extensions unless you also add a fallback for
+non-GCC compilers. You can, however, use GCC extensions and C99
+features in code that compiles only on GNU/Linux (such as
+lib/netdev-linux.c), because GCC is the system compiler there.