Talk to the journal ourselves using sendmsg() instead of linking
against libsystemd for sd_journal_sendv(). At the same time, we
can also avoid excessive copying.
The motivation for dropping the dependency is that we can
then use structured logging e.g. in a flatpak sandbox where
libsystemd may not be present in the runtime.
The code here is inspired by similar code in libvirt.
It turns out that the current approach of parsing g_log_structured
varargs is unworkable, because vprintf is not guaranteed to advance
the passed-in va_list. So, we have to reshuffle the argument list
a bit; I've come up with this approach:
g_log_structured (domain, level,
key-value pairs...
"MESSAGE", format,
printf arguments);
This requires a "MESSAGE" key to always be present, and it requires
the "MESSAGE"-format pair to be last, but it avoids an extra NULL
as marker after the key-value pairs. And it can be parsed with a
single pass over the va_list, without any va_copy.
Since we have G_LOG_USE_STRUCTURED, the separate ...structured()
convenience macros are pretty pointless, and I have dropped them
for now.
Replace the underlying write_string() call which is the ultimate result
of calling g_log() with a call to g_log_structured(). This means that
all g_log() calls will pass through the structured log handling code
path, as long as they are not already modified or dropped by the g_log()
code (fatal masks, aborts, etc.).
In the case that the default structured log writer is in use, this will
result in the same format of log output to stdout or stderr, as
previously happened. If a non-default writer is in use, it handles the
message as it sees fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
If outputting to a terminal which supports coloured output (rather than,
for example, redirecting to a file). This is only enabled for structured
log messages, where colour output support can be tested. It is not
enabled for non-structured log messages.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
In parallel with g_log(), add a new structured logging API, based around
g_log_structured() and various helper functions which are exposed
publicly to allow programs to build their own logging policies easily,
without having to rewrite a lot of gmessages.c because it’s all
internal.
See the expanded documentation at the top of gmessages.c for some
rationale. See the g_log_structured() documentation for some example
code.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
By default g_log_default_handler always assumes that stdout
and stderr are file descriptors 1 and 2. On Win32 this isn't
always the case as the win32 API functions AttachConsole and
freopen can be used to dynamically attach GUI applications to
a console and the file descriptors of stderr and stdout will
become different than 1 and 2.
Fix it by using fputs with the FILE directly instead of
using the file descriptors.
https://bugzilla.gnome.org/show_bug.cgi?id=692085
It seems to be common for people to use g_warning() or g_error() as pre-
and post-condition error reporting functions, which is not really what
they’re intended for. Similarly, it is generally a sign of bad API
design to use g_warning() to report errors — use GError instead.
Try and suggest this to the user in the hope that nice code results.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Instead of INCLUDES, which is deprecated in automake. Using AM_CPPFLAGS
also gives the hint that the -D argument should be a CPPFLAGS variable,
rather than CFLAGS.
When GLib had been told to expect message X, but then actually saw
message Y, it would log the "did not see expected message" error with
message Y's log level and domain, which makes no sense. Change it to
log with domain "GLib" and G_LOG_LEVEL_CRITICAL instead.
Also, include the expected domain in the error message, so that if
that's the reason why the expectation didn't match, you can tell that
from the error message.
Update glib/tests/testing.c for these changes; for all other test
programs in GLib and elsewhere, this change should not break any
existing tests, it should only improve the output on failure.
https://bugzilla.gnome.org/show_bug.cgi?id=727974
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Commit e53caad4 makes _g_log_abort() noreturn by calling abort()
unconditionally.
However, it is useful to be able to skip some log_abort() with a
debugger, to reach a point of interest. Revert back to previous
behaviour. Make g_assert_warning() noreturn by calling abort().
https://bugzilla.gnome.org/show_bug.cgi?id=711800
g_test_init() was calling _g_messages_set_exit_on_fatal() from
subprocesses, to make fatal log messages call _exit() rather than
abort(), but the function name is sort of confusing, and we don't
really need it anyway, since g_log() can just call g_test_subprocess()
instead and decide for itself.
Likewise, update g_assertion_message() to do the check itself, rather
than calling into gmessages to do it, and fix
g_assertion_message_expr() to also check whether it should exit or
abort. (Previously it always called abort(), although this didn't
actually matter since that was dead code until
test_nonfatal_assertions was added.)
https://bugzilla.gnome.org/show_bug.cgi?id=711800
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Debug messages are meant to give insight into how a process is
proceeding, and are unpredictable in nature. They also often have
line numbers in them.
This patch ignores debug messages in g_test_assert_expected_messages().
https://bugzilla.gnome.org/show_bug.cgi?id=710991
Allow passing a NULL domain to g_test_expect_message(), and more
importantly, don't crash if a message with a NULL domain gets logged
while there is an expected message.
