CODING_STYLE

   1 - 8ch indent, no tabs, except for files in man/ which are 2ch indent,
   2   and still no tabs
   3
   4 - We prefer /* comments */ over // comments, please. This is not C++, after
   5   all. (Yes we know that C99 supports both kinds of comments, but still,
   6   please!)
   7
   8 - Don't break code lines too eagerly. We do *not* force line breaks at
   9   80ch, all of today's screens should be much larger than that. But
  10   then again, don't overdo it, ~140ch should be enough really.
  11
  12 - Variables and functions *must* be static, unless they have a
  13   prototype, and are supposed to be exported.
  14
  15 - structs in MixedCase (with exceptions, such as public API structs),
  16   variables + functions in lower_case.
  17
  18 - The destructors always unregister the object from the next bigger
  19   object, not the other way around
  20
  21 - To minimize strict aliasing violations, we prefer unions over casting
  22
  23 - For robustness reasons, destructors should be able to destruct
  24   half-initialized objects, too
  25
  26 - Error codes are returned as negative Exxx. e.g. return -EINVAL. There
  27   are some exceptions: for constructors, it is OK to return NULL on
  28   OOM. For lookup functions, NULL is fine too for "not found".
  29
  30   Be strict with this. When you write a function that can fail due to
  31   more than one cause, it *really* should have "int" as return value
  32   for the error code.
  33
  34 - Do not bother with error checking whether writing to stdout/stderr
  35   worked.
  36
  37 - Do not log errors from "library" code, only do so from "main
  38   program" code. (With one exception: it is OK to log with DEBUG level
  39   from any code, with the exception of maybe inner loops).
  40
  41 - Always check OOM. There is no excuse. In program code, you can use
  42   "log_oom()" for then printing a short message, but not in "library" code.
  43
  44 - Do not issue NSS requests (that includes user name and host name
  45   lookups) from PID 1 as this might trigger deadlocks when those
  46   lookups involve synchronously talking to services that we would need
  47   to start up
  48
  49 - Do not synchronously talk to any other service from PID 1, due to
  50   risk of deadlocks
  51
  52 - Avoid fixed-size string buffers, unless you really know the maximum
  53   size and that maximum size is small. They are a source of errors,
  54   since they possibly result in truncated strings. It is often nicer
  55   to use dynamic memory, alloca() or VLAs. If you do allocate fixed-size
  56   strings on the stack, then it is probably only OK if you either
  57   use a maximum size such as LINE_MAX, or count in detail the maximum
  58   size a string can have. (DECIMAL_STR_MAX and DECIMAL_STR_WIDTH
  59   macros are your friends for this!)
  60
  61   Or in other words, if you use "char buf[256]" then you are likely
  62   doing something wrong!
  63
  64 - Stay uniform. For example, always use "usec_t" for time
  65   values. Do not mix usec and msec, and usec and whatnot.
  66
  67 - Make use of _cleanup_free_ and friends. It makes your code much
  68   nicer to read!
  69
  70 - Be exceptionally careful when formatting and parsing floating point
  71   numbers. Their syntax is locale dependent (i.e. "5.000" in en_US is
  72   generally understood as 5, while on de_DE as 5000.).
  73
  74 - Try to use this:
  75
  76       void foo() {
  77       }
  78
  79   instead of this:
  80
  81       void foo()
  82       {
  83       }
  84
  85   But it is OK if you do not.
  86
  87 - Single-line "if" blocks should not be enclosed in {}. Use this:
  88
  89   if (foobar)
  90           waldo();
  91
  92   instead of this:
  93
  94   if (foobar) {
  95           waldo();
  96   }
  97
  98 - Do not write "foo ()", write "foo()".
  99
 100 - Please use streq() and strneq() instead of strcmp(), strncmp() where applicable.
 101
 102 - Please do not allocate variables on the stack in the middle of code,
 103   even if C99 allows it. Wrong:
 104
 105   {
 106           a = 5;
 107           int b;
 108           b = a;
 109   }
 110
 111   Right:
 112
 113   {
 114           int b;
 115           a = 5;
 116           b = a;
 117   }
 118
 119 - Unless you allocate an array, "double" is always the better choice
 120   than "float". Processors speak "double" natively anyway, so this is
 121   no speed benefit, and on calls like printf() "float"s get promoted
 122   to "double"s anyway, so there is no point.
 123
 124 - Do not invoke functions when you allocate variables on the stack. Wrong:
 125
 126   {
 127           int a = foobar();
 128           uint64_t x = 7;
 129   }
 130
 131   Right:
 132
 133   {
 134           int a;
 135           uint64_t x = 7;
 136
 137           a = foobar();
 138   }
 139
 140 - Use "goto" for cleaning up, and only use it for that. i.e. you may
 141   only jump to the end of a function, and little else. Never jump
 142   backwards!
 143
 144 - Think about the types you use. If a value cannot sensibly be
 145   negative, do not use "int", but use "unsigned".
 146
 147 - Do not use types like "short". They *never* make sense. Use ints,
 148   longs, long longs, all in unsigned+signed fashion, and the fixed
 149   size types uint32_t and so on, as well as size_t, but nothing else.
 150
 151 - Public API calls (i.e. functions exported by our shared libraries)
 152   must be marked "_public_" and need to be prefixed with "sd_". No
 153   other functions should be prefixed like that.
 154
 155 - In public API calls, you *must* validate all your input arguments for
 156   programming error with assert_return() and return a sensible return
 157   code. In all other calls, it is recommended to check for programming
 158   errors with a more brutal assert(). We are more forgiving to public
 159   users then for ourselves! Note that assert() and assert_return()
 160   really only should be used for detecting programming errors, not for
 161   runtime errors. assert() and assert_return() by usage of _likely_()
 162   inform the compiler that he should not expect these checks to fail,
 163   and they inform fellow programmers about the expected validity and
 164   range of parameters.
 165
 166 - Never use strtol(), atoi() and similar calls. Use safe_atoli(),
 167   safe_atou32() and suchlike instead. They are much nicer to use in
 168   most cases and correctly check for parsing errors.
 169
 170 - For every function you add, think about whether it is a "logging"
 171   function or a "non-logging" function. "Logging" functions do logging
 172   on their own, "non-logging" function never log on their own and
 173   expect their callers to log. All functions in "library" code,
 174   i.e. in src/shared/ and suchlike must be "non-logging". Every time a
 175   "logging" function calls a "non-logging" function, it should log
 176   about the resulting errors. If a "logging" function calls another
 177   "logging" function, then it should not generate log messages, so
 178   that log messages are not generated twice for the same errors.
 179
 180 - Avoid static variables, except for caches and very few other
 181   cases. Think about thread-safety! While most of our code is never
 182   used in threaded environments, at least the library code should make
 183   sure it works correctly in them. Instead of doing a lot of locking
 184   for that, we tend to prefer using TLS to do per-thread caching (which
 185   only works for small, fixed-size cache objects), or we disable
 186   caching for any thread that is not the main thread. Use
 187   is_main_thread() to detect whether the calling thread is the main
 188   thread.
 189
 190 - Command line option parsing:
 191   - Do not print full help() on error, be specific about the error.
 192   - Do not print messages to stdout on error.
 193   - Do not POSIX_ME_HARDER unless necessary, i.e. avoid "+" in option string.
 194
 195 - Do not write functions that clobber call-by-reference variables on
 196   failure. Use temporary variables for these cases and change the
 197   passed in variables only on success.
 198
 199 - When you allocate a file descriptor, it should be made O_CLOEXEC
 200   right from the beginning, as none of our files should leak to forked
 201   binaries by default. Hence, whenever you open a file, O_CLOEXEC must
 202   be specified, right from the beginning. This also applies to
 203   sockets. Effectively this means that all invocations to:
 204
 205   a) open() must get O_CLOEXEC passed
 206   b) socket() and socketpair() must get SOCK_CLOEXEC passed
 207   c) recvmsg() must get MSG_CMSG_CLOEXEC set
 208   d) F_DUPFD_CLOEXEC should be used instead of F_DUPFD, and so on
 209
 210 - We never use the XDG version of basename(). glibc defines it in
 211   libgen.h. The only reason to include that file is because dirname()
 212   is needed. Everytime you need that please immediately undefine
 213   basename(), and add a comment about it, so that no code ever ends up
 214   using the XDG version!
 215
 216 - Use the bool type for booleans, not integers. One exception: in public
 217   headers (i.e those in src/systemd/sd-*.h) use integers after all, as "bool"
 218   is C99 and in our public APIs we try to stick to C89 (with a few extension).
 219
 220 - When you invoke certain calls like unlink(), or mkdir_p() and you
 221   know it is safe to ignore the error it might return (because a later
 222   call would detect the failure anyway, or because the error is in an
 223   error path and you thus couldn't do anything about it anyway), then
 224   make this clear by casting the invocation explicitly to (void). Code
 225   checks like Coverity understand that, and will not complain about
 226   ignored error codes. Hence, please use this:
 227
 228       (void) unlink("/foo/bar/baz");
 229
 230   instead of just this:
 231
 232       unlink("/foo/bar/baz");
 233
 234 - Don't invoke exit(), ever. It is not replacement for proper error
 235   handling. Please escalate errors up your call chain, and use normal
 236   "return" to exit from the main function of a process. If you
 237   fork()ed off a child process, please use _exit() instead of exit(),
 238   so that the exit handlers are not run.
 239
 240 - Please never use dup(). Use fcntl(fd, F_DUPFD_CLOEXEC, 3)
 241   instead. For two reason: first, you want O_CLOEXEC set on the new fd
 242   (see above). Second, dup() will happily duplicate your fd as 0, 1,
 243   2, i.e. stdin, stdout, stderr, should those fds be closed. Given the
 244   special semantics of those fds, it's probably a good idea to avoid
 245   them. F_DUPFD_CLOEXEC with "3" as parameter avoids them.
 246
 247 - When you define a destructor or unref() call for an object, please
 248   accept a NULL object and simply treat this as NOP. This is similar
 249   to how libc free() works, which accepts NULL pointers and becomes a
 250   NOP for them. By following this scheme a lot of if checks can be
 251   removed before invoking your destructor, which makes the code
 252   substantially more readable and robust.
 253
 254 - Related to this: when you define a destructor or unref() call for an
 255   object, please make it return the same type it takes and always
 256   return NULL from it. This allows writing code like this:
 257
 258             p = foobar_unref(p);
 259
 260   which will always work regardless if p is initialized or not, and
 261   guarantees that p is NULL afterwards, all in just one line.