X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=CodingStyle;h=d1ef65b5a31ab689ba619dd3f40ef120df6ff4c9;hb=ef47ed862c4f5c340a248db1759d75d968885fde;hp=bae8cd65ced7caf87a5bfe21a734fea8f1dc3853;hpb=3548d242578a9c8d6b0189d6bc9326bc26983881;p=cascardo%2Fovs.git

diff --git a/CodingStyle b/CodingStyle
index bae8cd65c..d1ef65b5a 100644
--- a/CodingStyle
+++ b/CodingStyle
@@ -3,7 +3,16 @@
 
 This file describes the coding style used in most C files in the Open
 vSwitch distribution.  However, Linux kernel code datapath directory
-follows the Linux kernel's established coding conventions.
+follows the Linux kernel's established coding conventions.  For the
+Windows kernel datapath code, use the coding style described in
+datapath-windows/CodingStyle.
+
+The following GNU indent options approximate this style:
+
+    -npro -bad -bap -bbb -br -blf -brs -cdw -ce -fca -cli0 -npcs -i4 -l79 \
+    -lc79 -nbfda -nut -saf -sai -saw -sbi4 -sc -sob -st -ncdb -pi4 -cs -bs \
+    -di1 -lp -il0 -hnl
+
 
 BASICS
 
@@ -162,6 +171,11 @@ 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.
 
+Functions in .c files should not normally be marked "inline", because
+it does not usually help code generation and it does suppress
+compilers warnings about unused functions.  (Functions defined in .h
+usually should be marked inline.)
+
 
 FUNCTION PROTOTYPES
 
@@ -414,12 +428,10 @@ prints 255 but printf("%u", -1) prints 4294967295.
 network protocol fields or in other circumstances where the exact
 format is important.
 
-  Declare bit-fields to be type "unsigned int" or "signed int".  Do
-*not* declare bit-fields of type "int": C89 allows these to be either
-signed or unsigned according to the compiler's whim.  (A 1-bit
-bit-field of type "int" may have a range of -1...0!)  Do not declare
-bit-fields of type _Bool or enum or any other type, because these are
-not portable.
+  Declare bit-fields to be signed or unsigned integer types or _Bool
+(aka bool).  Do *not* declare bit-fields of type "int": C99 allows
+these to be either signed or unsigned according to the compiler's
+whim.  (A 1-bit bit-field of type "int" may have a range of -1...0!)
 
   Try to order structure members such that they pack well on a system
 with 2-byte "short", 4-byte "int", and 4- or 8-byte "long" and pointer
@@ -515,7 +527,7 @@ global variables.
 
 C DIALECT
 
-  Some C99 features are OK because they are widely implemented:
+  Most C99 features are OK because they are widely implemented:
 
     * Flexible array members (e.g. struct { int foo[]; }).
 
@@ -529,20 +541,24 @@ C DIALECT
     * bool and <stdbool.h>, but don't assume that bool or _Bool can
       only take on the values 0 or 1, because this behavior can't be
       simulated on C89 compilers.
+      Also, don't assume that a conversion to bool or _Bool follows
+      C99 semantics.  I.e. use "(bool)(some_value != 0)" rather than
+      "(bool)some_value".  The latter might produce unexpected results
+      on non-C99 environments.  For example, if bool is implemented as
+      a typedef of char and some_value = 0x10000000.
 
     * Designated initializers (e.g. "struct foo foo = {.a = 1};" and
       "int a[] = {[2] = 5};").
 
-  Don't use other C99 features that are not widely implemented in
-older compilers:
-
-    * Don't mix declarations and code within a block.
+    * Mixing of declarations and code within a block.  Please use this
+      judiciously; keep declarations nicely grouped together in the
+      beginning of a block if possible.
 
-    * Don't use declarations in iteration statements (e.g. don't write
+    * Use of declarations in iteration statements (e.g.
       "for (int i = 0; i < 10; i++)").
 
-    * Don't put a trailing comma in an enum declaration (e.g. don't
-      write "enum { x = 1, };").
+    * Use of a trailing comma in an enum declaration (e.g.
+      "enum { x = 1, };").
 
   As a matter of style, avoid // comments.