X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=CODING_STYLE;h=7fd4af8b873ceaeb875dc2ec7ded955eb7ba4465;hp=dbadfbdb5441adf3ae53a0ebec458bf2726cd151;hb=fc157480fbf58337411532485f377afff5c794a1;hpb=1cfc78c91965df340cdde100ad6cb3ed50b28927

diff --git a/CODING_STYLE b/CODING_STYLE
index dbadfbdb5..7fd4af8b8 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -295,22 +295,50 @@
   EXIT_FAILURE and EXIT_SUCCESS as defined by libc.
 
 - The order in which header files are included doesn't matter too
-  much. However, please try to include the headers of external
-  libraries first (these are all headers enclosed in <>), followed by
-  the headers of our own public headers (these are all headers
-  starting with "sd-"), internal utility libraries from src/shared/,
-  followed by the headers of the specific component. Or in other
-  words:
-
-          #include <stdio.h>
-          #include "sd-daemon.h"
-          #include "util.h"
-          #include "frobnicator.h"
-
-  Where stdio.h is a public glibc API, sd-daemon.h is a public API of
-  our own, util.h is a utility library header from src/shared, and
-  frobnicator.h is an placeholder name for any systemd component. The
-  benefit of following this ordering is that more local definitions
-  are always defined after more global ones. Thus, our local
-  definitions will never "leak" into the global header files, possibly
-  altering their effect due to #ifdeffery.
+  much. systemd-internal headers must not rely on an include order, so
+  it is safe to include them in any order possible.
+  However, to not clutter global includes, and to make sure internal
+  definitions will not affect global headers, please always include the
+  headers of external components first (these are all headers enclosed
+  in <>), followed by our own exported headers (usually everything
+  that's prefixed by "sd-"), and then followed by internal headers.
+  Furthermore, in all three groups, order all includes alphabetically
+  so duplicate includes can easily be detected.
+
+- To implement an endless loop, use "for (;;)" rather than "while
+  (1)". The latter is a bit ugly anyway, since you probably really
+  meant "while (true)"... To avoid the discussion what the right
+  always-true expression for an infinite while() loop is our
+  recommendation is to simply write it without any such expression by
+  using "for (;;)".
+
+- Never use the "off_t" type, and particularly avoid it in public
+  APIs. It's really weirdly defined, as it usually is 64bit and we
+  don't support it any other way, but it could in theory also be
+  32bit. Which one it is depends on a compiler switch chosen by the
+  compiled program, which hence corrupts APIs using it unless they can
+  also follow the program's choice. Moreover, in systemd we should
+  parse values the same way on all architectures and cannot expose
+  off_t values over D-Bus. To avoid any confusion regarding conversion
+  and ABIs, always use simply uint64_t directly.
+
+- Commit message subject lines should be prefixed with an appropriate
+  component name of some kind. For example "journal: ", "nspawn: " and
+  so on.
+
+- Do not use "Signed-Off-By:" in your commit messages. That's a kernel
+  thing we don't do in the systemd project.
+
+- Avoid leaving long-running child processes around, i.e. fork()s that
+  are not followed quickly by an execv() in the child. Resource
+  management is unclear in this case, and memory CoW will result in
+  unexpected penalties in the parent much much later on.
+
+- Don't block execution for arbitrary amounts of time using usleep()
+  or a similar call, unless you really know what you do. Just "giving
+  something some time", or so is a lazy excuse. Always wait for the
+  proper event, instead of doing time-based poll loops.
+
+- To determine the length of a constant string "foo", don't bother
+  with sizeof("foo")-1, please use strlen("foo") directly. gcc knows
+  strlen() anyway and turns it into a constant expression if possible.