Lines Matching refs:and
12 - 8ch indent, no tabs, except for files in `man/` which are 2ch indent, and
13 still no tabs, and shell scripts, which are 4ch indent, and no tabs either.
23 overdo it, ~109ch should be enough really. The `.editorconfig`, `.vimrc` and
94 expressions, and align them vertically. Define both an enum and a type for
112 "invalid" enum value, and set it to `-EINVAL`. That way the enum type can
122 ## Code Organization and Semantics
127 set of conservative and common extensions, such as fixed size integer types
131 have different size in memory and slightly different semantics, also see
132 below.) Both for internal and external code it's OK to use even newer
133 features and GCC extension than "gnu11", as long as there's reasonable
138 structs), variables and functions in `snake_case`.
140 - Avoid static variables, except for caches and very few other cases. Think
150 failure. Use temporary variables for these cases and change the passed in
155 mutable objects, and call-by-reference return parameters. Input parameters
157 indicate they are input-only and not changed by the function. Return
176 includes, and to make sure internal definitions will not affect global
179 (usually everything that's prefixed by `sd-`), and then followed by internal
187 break in threaded programs, and usually would require locking there), and as
189 said, there are many cases where they explicitly make a lot of sense, and are
190 OK to use. For example, the log level and target in `log.c` is stored in a
191 global variable, and that's OK and probably expected by most. Also in many
193 please be careful however, and think about threading. Only use static
202 and Linux/GNU-specific APIs, we generally prefer the POSIX APIs. If there
203 aren't, we are happy to use GNU or Linux APIs, and expect non-GNU
256 - Use `goto` for cleaning up, and only use it for that. I.e. you may only jump
257 to the end of a function, and little else. Never jump backwards!
263 and actually even faster at execution. Hence:
288 `sizeof("foo")-1`, please use `strlen()` instead (both gcc and clang optimize
290 array. In that case use `STRLEN()`, which evaluates to a static constant and
294 actually booleans (or "boolean-like"), and not for variables that are really
295 numeric. Specifically, if you have an `int b` and it's only used in a boolean
297 have more than two semantic values, and you want to compare for non-zero,
299 as the value range and semantical behaviour is directly clear from the
315 `NULL` object and simply treat this as NOP. This is similar to how libc
316 `free()` works, which accepts `NULL` pointers and becomes a NOP for them. By
318 your destructor, which makes the code substantially more readable and robust.
321 object, please make it return the same type it takes and always return `NULL`
328 which will always work regardless if `p` is initialized or not, and
342 `errno`), and >= 0 on success. Use the RET_NERRNO() helper if you are looking
367 programming error with `assert_return()` and return a sensible return
370 ourselves! Note that `assert()` and `assert_return()` really only should be
371 used for detecting programming errors, not for runtime errors. `assert()` and
373 not expect these checks to fail, and they inform fellow programmers about the
374 expected validity and range of parameters.
376 - When you invoke certain calls like `unlink()`, or `mkdir_p()` and you know it
378 detect the failure anyway, or because the error is in an error path and you
381 that, and will not complain about ignored error codes. Hence, please use
408 `EXIT_FAILURE` and `EXIT_SUCCESS` as defined by libc.
415 and expect their callers to log. All functions in "library" code, i.e. in
416 `src/shared/` and suchlike must be "non-logging". Every time a "logging"
422 generally always fine and welcome.)
447 - Avoid fixed-size string buffers, unless you really know the maximum size and
452 have. (`DECIMAL_STR_MAX` and `DECIMAL_STR_WIDTH` macros are your friends for
458 - Make use of `_cleanup_free_` and friends. It makes your code much nicer to
459 read (and shorter)!
469 parameters. `alloca_safe()` memory is released at the end of a function, and
485 unclear in this case, and memory CoW will result in unexpected penalties in
494 so that interrupted system calls are automatically restarted, and we minimize
501 first (i.e. `%` → `%%`), and then do C-style escaping where necessary.
503 - Be exceptionally careful when formatting and parsing floating point
523 long`, all in unsigned and signed fashion, and the fixed-size types
525 and so on, as well as `size_t`, but nothing else. Do not use kernel types
526 like `u32` and so on, leave that to the kernel.
529 `usec` and `msec`, and `usec` and whatnot.
531 - Never use the `off_t` type, and particularly avoid it in public APIs. It's
532 really weirdly defined, as it usually is 64-bit and we don't support it any
536 systemd we should parse values the same way on all architectures and cannot
538 and ABIs, always use simply `uint64_t` directly.
542 benefit, and on calls like `printf()` `float`s get promoted to `double`s
547 is C99 and in our public APIs we try to stick to C89 (with a few extensions;
552 - Do not issue NSS requests (that includes user name and hostname lookups)
568 - `socket()` and `socketpair()` must get `SOCK_CLOEXEC` passed,
570 - `F_DUPFD_CLOEXEC` should be used instead of `F_DUPFD`, and so on,
575 were specified by the user and hence might actually refer to other types of
585 - If you parse a command line, and want to store the parsed parameters in
587 been following this naming rule in most of our tools, and we should continue
589 and makes it clear why it is OK that they are global variables.
598 - Variables and functions **must** be static, unless they have a prototype, and
602 must be marked `_public_` and need to be prefixed with `sd_`. No
612 useful for client applications. Hence, please be careful and avoid `const` on
617 - When referring to a configuration file option in the documentation and such,
621 - When referring to a command line option in the documentation and such, please
633 - Please use `streq()` and `strneq()` instead of `strcmp()`, `strncmp()` where
637 - Never use `strtol()`, `atoi()` and similar calls. Use `safe_atoli()`,
638 `safe_atou32()` and suchlike instead. They are much nicer to use in most
639 cases and correctly check for parsing errors.
641 - `htonl()`/`ntohl()` and `htons()`/`ntohs()` are weird. Please use `htobe32()`
642 and `htobe16()` instead, it's much more descriptive, and actually says what
643 really is happening, after all `htonl()` and `htons()` don't operate on
644 `long`s and `short`s as their name would suggest, but on `uint32_t` and
660 handling. Please escalate errors up your call chain, and use normal `return`
668 time you need that please immediately undefine `basename()`, and add a
672 of paths) and `NAME_MAX` (for checking maximum size of filenames).
673 `FILENAME_MAX` is not POSIX, and is a confusingly named alias for `PATH_MAX`
680 name of some kind. For example "journal: ", "nspawn: " and so on.