summaryrefslogtreecommitdiff
path: root/src/shared/serialize.c
Commit message (Collapse)AuthorAgeFilesLines
* util: drop missing.h from util.hYu Watanabe2018-12-041-0/+1
|
* util-lib: move open_serialization_fd() to serialize.cLennart Poettering2018-12-021-0/+23
| | | | | | It definitely fits better there. No code changes, just some rearranging.
* coccinelle: make use of SYNTHETIC_ERRNOZbigniew Jędrzejewski-Szmek2018-11-221-4/+4
| | | | | | | | | | | Ideally, coccinelle would strip unnecessary braces too. But I do not see any option in coccinelle for this, so instead, I edited the patch text using search&replace to remove the braces. Unfortunately this is not fully automatic, in particular it didn't deal well with if-else-if-else blocks and ifdefs, so there is an increased likelikehood be some bugs in such spots. I also removed part of the patch that coccinelle generated for udev, where we returns -1 for failure. This should be fixed independently.
* Move LONG_LINE_MAX definition to fileio.hZbigniew Jędrzejewski-Szmek2018-11-141-1/+1
| | | | | | | | | | | All users of the macro (except for one, in serialize.c), use the macro in connection with read_line(), so they must include fileio.h. Let's not play libc games and require multiple header file to be included for the most common use of a function. The removal of def.h includes is not exact. I mostly went over the commits that switch over to use read_line() and add def.h at the same time and reverted the addition of def.h in those files.
* Introduce fmkostemp_safe and use it in testsZbigniew Jędrzejewski-Szmek2018-10-261-1/+1
| | | | No functional change.
* core: rework serializationLennart Poettering2018-10-261-0/+190
Let's be more careful with what we serialize: let's ensure we never serialize strings that are longer than LONG_LINE_MAX, so that we know we can read them back with read_line(…, LONG_LINE_MAX, …) safely. In order to implement this all serialization functions are move to serialize.[ch], and internally will do line size checks. We'd rather skip a serialization line (with a loud warning) than write an overly long line out. Of course, this is just a second level protection, after all the data we serialize shouldn't be this long in the first place. While we are at it also clean up logging: while serializing make sure to always log about errors immediately. Also, (void)ify all calls we don't expect errors in (or catch errors as part of the general fflush_and_check() at the end.