Commit Graph

13 Commits

Author SHA1 Message Date
Lubomir Rintel
e69d386975 all: use the elvis operator wherever possible
Coccinelle:

  @@
  expression a, b;
  @@
  -a ? a : b
  +a ?: b

Applied with:

  spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .

With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.

Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.
2018-05-10 14:36:58 +02:00
Beniamino Galvani
1b5925ce88 all: remove consecutive empty lines
Normalize coding style by removing consecutive empty lines from C
sources and headers.

https://github.com/NetworkManager/NetworkManager/pull/108
2018-04-30 16:24:52 +02:00
Thomas Haller
3b03b2caee keyfile: don't hack certain properties to be skipped in reader
For writer there is no such hack either. The property-info table
should describe whether to skip a property or not.
2018-04-19 09:45:19 +02:00
Thomas Haller
8c4ce431a6 keyfile: no special handling to set parser_no_check_key for certain settings
Do not have multiple ways of expressing a certain thing. There is
a way how to express that the parser shouldn't check for keys, and
that is via the parse-information. No extra hacks.
2018-04-19 09:36:41 +02:00
Thomas Haller
9c91d44667 keyfile: drop unused set_default_for_missing_key() 2018-04-19 09:36:41 +02:00
Thomas Haller
7e3b7295a4 keyfile: rework handling of checking for whether a key exists in reader
Rework this to have a value "parser_no_check_key" so that:

- the default value for this is FALSE, so that we don't need to
  explicitly set it in @parse_infos to only get the default.
  Contrary to check_for_key.
- check_for_key only had meaning when also "parser" was set.
  That means, the value was really "pip->parser && pip->check_for_key".
  That came from the fact, that orginally this was tracked as
  key_parsers array, which had "parser" always set.
  That is confusing, don't do that. The field "parser_no_check_key"
  has it's meaning, regardless of whether "parser" is set.
2018-04-19 09:36:41 +02:00
Thomas Haller
87cc309249 keyfile: various cleanup of error paths in keyfile handling 2018-04-19 09:36:41 +02:00
Thomas Haller
4dc933174e keyfile: don't special case skipping connection.read-only property in writer 2018-04-19 09:36:41 +02:00
Thomas Haller
94a96b70d0 keyfile: rework handling not skipping default-values in writer 2018-04-19 09:36:41 +02:00
Thomas Haller
a5c026f90e libnm/keyfile: replace dummy writer implementation with flag to skip writing 2018-04-19 09:36:41 +02:00
Thomas Haller
3695d5273a libnm/keyfile: merge parser/writer vtables for keyfile properties 2018-04-19 09:36:41 +02:00
Thomas Haller
21f6058cfe libnm/keyfile: merge keyfile sources (pt2, merge nm-keyfile-writer.c)
Splitting keyfile handling in two "reader.c" and "writer.c" files
is not helpful. What is most interesting, is to see how property XYZ
is serialized to keyfile, and to verify that the parser does the
inverse. For that, it's easier if both the write_xzy() and parse_xyz()
function are beside each other, and not split accross files.

The more important reason is, that both reader and writer have their
separate handler arrays, for special handling of certain properties:
@key_parsers and @key_writers. These two should not be separate but will
be merged. Since they reference static functions, these functions must
all be in the same source file (unless, we put them into headers, which
would be unnecessary complex).

No code was changed, only moved.
2018-04-19 09:36:41 +02:00
Thomas Haller
f99dc6b936 libnm/keyfile: merge keyfile sources (pt1, rename nm-keyfile-reader.c)
I am going to merge the files for keyfile handling in libnm-core.
There is a reason for that, I'll tell you next.
2018-04-19 09:36:41 +02:00