We already allowed variables to be declared in the middle of a function
(whenever a new scope was opened), so this isn't such a big change. Sometimes
we would open a scope just to work around this prohibition.
But sometimes the code can be much clearer if the variable is declared
somewhere in the middle of a scope, in particular if the declaration is
combined with initialization or acquisition of some resources. So let's allow
this, but keep things in the old style, unless there's a good reason to move
the variable declaration to a different place.
# '-Wold-style-definition',
# '-Wpointer-arith',
# '-Winit-self',
# '-Wold-style-definition',
# '-Wpointer-arith',
# '-Winit-self',
-# '-Wdeclaration-after-statement',
# '-Wfloat-equal',
# '-Wsuggest-attribute=noreturn',
# '-Werror=missing-prototypes',
# '-Wfloat-equal',
# '-Wsuggest-attribute=noreturn',
# '-Werror=missing-prototypes',
add_project_arguments(cc.get_supported_arguments(possible_cc_flags), language : 'c')
# "negative" arguments: gcc on purpose does not return an error for "-Wno-"
add_project_arguments(cc.get_supported_arguments(possible_cc_flags), language : 'c')
# "negative" arguments: gcc on purpose does not return an error for "-Wno-"
-# arguments, just emits a warnings. So test for the "positive" version instead.
+# arguments, just emits a warning. So test for the "positive" version instead.
foreach arg : ['unused-parameter',
'missing-field-initializers',
'unused-result',
foreach arg : ['unused-parameter',
'missing-field-initializers',
'unused-result',
executable('elogind-user-runtime-dir',
executable('elogind-user-runtime-dir',
executable('elogind-user-runtime-dir',
executable('elogind-user-runtime-dir',
executable('elogind-user-runtime-dir',
executable('elogind-user-runtime-dir',
+executable('elogind-user-runtime-dir',
executable('elogind-user-runtime-dir',
user_runtime_dir_sources,
include_directories : includes,
executable('elogind-user-runtime-dir',
user_runtime_dir_sources,
include_directories : includes,