- Do not 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.
+ size types uint32_t and so on, as well as size_t, but nothing
+ else. Do not use kernel types like u32 and so on, leave that to the
+ kernel.
- Public API calls (i.e. functions exported by our shared libraries)
must be marked "_public_" and need to be prefixed with "sd_". No
c) recvmsg() must get MSG_CMSG_CLOEXEC set
d) F_DUPFD_CLOEXEC should be used instead of F_DUPFD, and so on
-- We never use the XDG version of basename(). glibc defines it in
- libgen.h. The only reason to include that file is because dirname()
+- We never use the POSIX version of basename() (which glibc defines it in
+ libgen.h), only the GNU version (which glibc defines in string.h).
+ The only reason to include libgen.h is because dirname()
is needed. Everytime you need that please immediately undefine
basename(), and add a comment about it, so that no code ever ends up
- using the XDG version!
+ using the POSIX version!
- Use the bool type for booleans, not integers. One exception: in public
headers (i.e those in src/systemd/sd-*.h) use integers after all, as "bool"
- When returning a return code from main(), please preferably use
EXIT_FAILURE and EXIT_SUCCESS as defined by libc.
+
+- The order in which header files are included doesn't matter too
+ 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.