+ lookups) from PID 1 as this might trigger deadlocks when those
+ lookups involve synchronously talking to services that we would need
+ to start up
+
+- Don't synchronously talk to any other service from PID 1, due to
+ risk of deadlocks
+
+- Avoid fixed sized string buffers, unless you really know the maximum
+ size and that maximum size is small. They are a source of errors,
+ since they possibly result in truncated strings. Often it is nicer
+ to use dynamic memory, alloca() or VLAs. If you do allocate fixed
+ size strings on the stack, then it's probably only OK if you either
+ use a maximum size such as LINE_MAX, or count in detail the maximum
+ size a string can have. (DECIMAL_STR_MAX and DECIMAL_STR_WIDTH
+ macros are your friends for this!)
+
+ Or in other words, if you use "char buf[256]" then you are likely
+ doing something wrong!
+
+- Stay uniform. For example, always use "usec_t" for time
+ values. Don't usec mix msec, and usec and whatnot.
+
+- Make use of _cleanup_free_ and friends. It makes your code much
+ nicer to read!
+
+- Be exceptionally careful when formatting and parsing floating point
+ numbers. Their syntax is locale dependent (i.e. "5.000" in en_US is
+ generally understood as 5, while on de_DE as 5000.).
+
+- Try to use this:
+
+ void foo() {
+ }
+
+ instead of this:
+
+ void foo()
+ {
+ }
+
+ But it's OK if you don't.
+
+- Don't write "foo ()", write "foo()".
+
+- Please use streq() and strneq() instead of strcmp(), strncmp() where applicable.
+
+- Please do not allocate variables on the stack in the middle of code,
+ even if C99 allows it. Wrong:
+
+ {
+ a = 5;
+ int b;
+ b = a;
+ }
+
+ Right:
+
+ {
+ int b;
+ a = 5;
+ b = a;
+ }
+
+- Unless you allocate an array, "double" is always the better choice
+ than "float". Processors speak "double" natively anyway, so this is
+ no speed benefit, and on calls like printf() "float"s get upgraded
+ to "double"s anyway, so there is no point.
+
+- Don't invoke functions when you allocate variables on the stack. Wrong:
+
+ {
+ int a = foobar();
+ uint64_t x = 7;
+ }
+
+ Right:
+
+ {
+ int a;
+ uint64_t x = 7;
+
+ a = foobar();
+ }
+
+- Use "goto" for cleaning up, and only use it for that. i.e. you may
+ only jump to the end of a function, and little else. Never jump
+ backwards!
+
+- Think about the types you use. If a value cannot sensibly be
+ negative don't use "int", but use "unsigned".
+
+- Don't use types like "short". They *never* make sense. Use ints,
+ longs, long longs, all in unsigned+signed fashion, and the fixed
+ size types uint32_t and so on, as well as size_t but nothing else.
+
+- Public API calls (i.e. functions exported by our shared libraries)
+ must be marked "_public_" and need to be prefixed with "sd_". No
+ other functions should be prefixed like that.
+
+- In public API calls you *must* validate all your input arguments for
+ programming error with assert_return() and return a sensible return
+ code. In all other calls it is recommended to check for programming
+ errors with a more brutal assert(). We are more forgiving to public
+ users then for ourselves! Note that assert() and assert_return()
+ really only should be used for detecting programming errors, not for
+ runtime errors. assert() and assert_return() by usage of _likely_()
+ inform the compiler that he shouldn't expect these checks to fail,
+ and they inform fellow programmers about the expected validity and
+ range of parameters.
+
+- Never use strtol(), atoi() and similar calls. Use safe_atoli(),
+ safe_atou32() and suchlike instead. They are much nicer to use in
+ most cases and correctly check for parsing errors.