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.
Look for a macro G_LOG_USE_STRUCTURED, and if it is defined, use
g_log_structured instead of g_log when defining g_warning and friends.
This avoids the extra complication of going through g_logv _and_
g_log_structured to get a message logged; it also lets us pass
the code-related fields.
We don't do this unconditionally (yet), since some users might
rely on the more fine-grained fatality support in g_logv. It has
also been proven problematic in the past to inject a dependency
on bleeding-edge API via a widely-used macro.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
g_socket_listener_add_address() is synchronous; all of the events will
have been emitted before it returns and it doesn't queue any sources.
The test was unintentionally depending on the fact that
g_main_context_iterate(NULL, TRUE) would return anyway (at least the
first time it was called), but that's no longer true after e4ee307.
https://bugzilla.gnome.org/show_bug.cgi?id=768968
GCC fails to build because of the trailing arguments, not part of the
format:
../../glib/gmessages.c: In function 'g_log_default_handler':
../../glib/gmessages.c:2385:21: error: too many arguments for format
[-Werror=format-extra-args]
NULL);
^
The documentation for `__attribute__((format(...)))` in GCC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
States that the second index must be 0 for functions that are not
available to be checked, like for vprintf-style functions. In this case
it's also appropriate because of the trailing arguments.
The sd-journal API in systemd, upon which the structured logging API is
modelled, also uses 0 as the second argument for the format attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
It turns out that g_info_structured (format, ...) makes
g_info_structured ("Hey!") not work, since it requires at
least one argument after the format string. So shorten
the argument list to just ...
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
glib-compile-resources --generate is supposed to automatically detect
whether to generate source code or header from the target's file extension.
However, this only worked for C; extend this to include the canonical
C++ filename extensions. Also make the check case insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=747134
Include the filename for the file in question in many of the
error messages in glocalfile.c. This is useful information when
diagnosing such errors, so make it easily available.
http://bugzilla.gnome.org/show_bug.cgi?id=754012
The recently-added GIO tools is intended to be built on all platforms, so
adjust the code a bit to enable this:
-Use gssize instead of ssize_t, as ssize_t is not supported by all
compilers.
-Include io.h on Windows, and define STDIN_FILENO and STDOUT_FILENO if
necessary on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=768357
Ensure that @key is non-%NULL on g_settings_reset().
It turns out that using g_settings_reset() with %NULL key (although
invalid as per the API documentation and not possible via bindings)
accidentally produces the same effect as the _reset_all() API that we
are about to add.
Add the standard precondition checks to prevent that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=744678
The macro could be used at initialization time to avoid having an
unitialized dict, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the asv
parameter is actually "GVariant *".
https://bugzilla.gnome.org/show_bug.cgi?id=766370
The macro could be used at initialization time to avoid having an
unitialized builder, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the
variant_type parameter is actually "const GVariantType
*". Unfortunately I have no idea how to make it possible to also pass
a "const gchar *" parameter without warning.
https://bugzilla.gnome.org/show_bug.cgi?id=766370
revents is set in the same function after some lines. This check was
using revents from previous loop. This had the problem of causing two
poll execution for every changes to poll records.
Note that is not possible to move the code after revents is updated
as probably poll_changed is TRUE causing the function to exit.
Adapted from a patch by Frediano Ziglio,
https://bugzilla.gnome.org/show_bug.cgi?id=761102
This reduce the frequency the loop is waked up adding and removing
file descriptors or timeouts.
Considering that to support recursion events are removed from list and
added again this reduce iteration number a lot.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=761102
GSettings objects were not unreffed in test_flags, test_enums and
test_ranges tests and when we skip internationalization tests, ie
test_l10n(_context).
https://bugzilla.gnome.org/show_bug.cgi?id=768560
historically, DEBUG_CODE(gtype.c) and IF_DEBUG(gobject.c, gsignal.c)
macros are used to support debugging messages about object bookkeeping
and signal emission.
DEBUG_CODE has never been used in gtype.c. IF_DEBUG, when used, must be
accompanied by an extra #ifdef G_ENABLE_DEBUG. this is cumbersome.
this patch add a new macro GOBJECT_IF_DEBUG based on DEBUG_CODE as
a replacement for both DEBUG_CODE and IF_DEBUG.
https://bugzilla.gnome.org/show_bug.cgi?id=729914
The two known use-cases for autolaunching are:
* X-forwarding: "ssh -Y myhost myapp" resulting in a
session bus on myhost but an X server on the original host
* Legacy desktop environments on OSs without D-Bus integration:
e.g. running a single GNOME or KDE app under fvwm or something,
without a session dbus-daemon being started by either systemd,
gnome-session, or OS integration scripts analogous to Debian's
/etc/X11/Xsession.d/75dbus_dbus-launch
In either case, an X11 DISPLAY is also needed.
"dbus-launch --autolaunch" doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid "split brain" situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run "dbus-launch --autolaunch"
unless getenv("DISPLAY") returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.
This change was originally made to work around a race condition in
subprocess spawning (Debian bug #737380, GNOME bug #711090) but
it seems valid in its own right.
In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as "systemd --user", gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).
Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
