Lines Matching refs:we

117   compatibility. Since we typically want to allow adding new enum values to an
124 - For our codebase we intend to use ISO C11 *with* GNU extensions (aka
125   "gnu11"). Public APIs (i.e. those we expose via `libsystemd.so`
128   from `<inttypes.h>`), so that we don't force consuming programs into C11
129   mode. (This discrepancy in particular means one thing: internally we use C99
143   in them. Instead of doing a lot of locking for that, we tend to prefer using
145   objects), or we disable caching for any thread that is not the main
192   cases we cache data in global variables. If you add more caches like this,
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
259 - To minimize strict aliasing violations, we prefer unions over casting.
494   so that interrupted system calls are automatically restarted, and we minimize
521   generic byte, we generally prefer the unsigned variant `uint8_t`. Do not use
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
547   is C99 and in our public APIs we try to stick to C89 (with a few extensions;
554   synchronously talking to services that we would need to start up.
576   file system objects. This is a good idea so that we don't end up blocking on
587   been following this naming rule in most of our tools, and we should continue
646   hence we might want to call it "big endian" right-away.
682 - Do not use "Signed-Off-By:" in your commit messages. That's a kernel thing we