Skip to content
GitLab
Menu
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
NetworkManager
NetworkManager
Commits
ac14ebb3
Commit
ac14ebb3
authored
May 16, 2019
by
Thomas Haller
Browse files
CONTRIBUTING: explain how assertions work for us
parent
03ab1466
Pipeline
#37282
passed with stages
in 54 minutes
Changes
1
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
CONTRIBUTING
View file @
ac14ebb3
...
...
@@ -43,5 +43,59 @@ GNU General Public License, version 2 or later, or, if another license
is specified as governing the file or directory being modified, such
other license. See the file COPYING in this directory for details.
Assertions in NetworkManager code
=================================
There are different kind of assertions. Use the one that is appropriate.
1) g_return_*() from glib. This is usually enabled in release builds and
can be disabled with G_DISABLE_CHECKS define. This uses g_log() with
a cG_LOG_LEVEL_CRITICAL level (which allows the program to continue,
until G_DEBUG=fatal-criticals or G_DEBUG=fatal-warnings is set). As such,
this is the preferred way for assertions that are commonly enabled.
Make a mild attempt to work around such assertion failure, but don't try
to hard. A failure of g_return_*() assertion might allow the process
to continue, but there is no guarantee.
2) nm_assert() from NetworkManager. This is disabled by default in release
builds, but enabled if you build --with-more-assertions. See "WITH_MORE_ASSERTS"
define. This is preferred for assertions that are expensive to check or
nor necessary to check frequently (stuff that is really not expected to
fail). Use this deliberately and assume it's not present in production builds.
3) g_assert() from glib. This is used in unit tests and commonly enabled
in release builds. It can be disabled with G_DISABLE_ASSERT assert
define. Since this results in a hard crash on assertion failure, you
should almost always prefer g_return_*() over this (except unit tests).
4) assert() from <assert.h>. It is usually enabled in release builds and
can be disabled with NDEBUG define. Don't use it in NetworkManager,
it's basically like g_assert().
5) g_log() from glib. These are always compiled in, depending on the levels
these are assertions too. G_LOG_LEVEL_ERROR aborts the program, G_LOG_LEVEL_CRITICAL
logs a critical warning (like g_return_*(), see G_DEBUG=fatal-criticals)
and G_LOG_LEVEL_WARNING logs a warning (see G_DEBUG=fatal-warnings).
G_LOG_LEVEL_DEBUG level is usually not printed, unless G_MESSAGES_DEBUG environment
is set.
In general, avoid using g_log() in NetworkManager. We have nm-logging instead.
From a library like libnm it might make sense to log warnings (if someting
is really wrong) or debug messages. But better don't. If it's important,
find a way to report the notification via the API to the caller. If it's
not important, keep silent.
6) g_warn_if_*() from glib. These are always compiled in and log a G_LOG_LEVEL_WARNING
warning. Don't use this.
7) G_TYPE_CHECK_INSTANCE_CAST() from glib. Unless building with "WITH_MORE_ASSERTS",
we disable G_DISABLE_CAST_CHECKS. This means, cast macros like NM_DEVICE(ptr)
translate to plain C pointer casts. Use the cast macros deliberately, in production
code they are cheap, with debugging enabled they assert that the pointer is valid.
Of course, every assertion failure is a bug, and they must not have side effects.
Theoretically, you are welcome to disable G_DISABLE_CHECKS and G_DISABLE_ASSERT
in production builds. In practice, nobody tests such a configuration, so beware.
For testing, you also want to run NetworkManager with G_DEBUG=fatal-warnings
to crash un critical and warn g_log() messages.
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment