This is an API analogue of the G_MESSAGES_DEBUG environment variable. It
is intended to be exposed outside applications (for example, as a D-Bus
interface — see follow-up commits) so that there is a uniform interface
for controlling the debug output of an application.
Helps: #1190
This allows programs that want to change how log messages are printed,
such as gnome-terminal (gnome-terminal#42) and Flatpak, to override
the log-writer or the legacy log-handler without having to reimplement
the G_MESSAGES_DEBUG filtering logic.
Signed-off-by: Simon McVittie <smcv@collabora.com>
GLib code normally prints info and debug messages to stdout,
but that interferes with programs that are documented to produce
machine-readable output such as JSON or XML on stdout. In particular,
if such a program uses a GLib-based library, setting G_MESSAGES_DEBUG
will typically result in that library's debug messages going to the
program's stdout and corrupting the machine-readable output.
Unix programs can avoid this by using dup2() to move the original stdout
to another fd, then dup2() again to make the new stdout a copy of stderr,
but it's easier if we provide a way to not write debug messages to
stdout in the first place. Calling
g_log_writer_default_set_use_stderr (TRUE) results in behaviour
resembling Python's logging.basicConfig(), with all diagnostics going
to stderr.
Suggested by Allison Karlitskaya on glib#2087.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In many places the pattern
static gboolean warned_once = FALSE;
if (!warned_once)
{
g_warning ("This and that");
warned_once = TRUE;
}
is used to not spam the same warning message over and over again. Add a
helper in glib for this, allowing the above statement to be changed to
g_warning_once ("This and that");
Only redefine g_message() and friends to use structured logging if the
compiling code is OK with depending on GLib functionality from ≥2.56.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1847
I’m fed up of trying to read these and having my head done in by mixed
tabs and spaces.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When compiling with G_LOG_USE_STRUCTURED, g_message(), g_debug(), etc.
use g_log_structured(). The message format string and its format
arguments are passed as the final set of arguments in a longer varargs
list, which includes the log domain and level (and other) fields.
Passing the message format in this way means it’s not possible for the
compiler to know to check its format placeholders when compiling with
-Wformat.
Fix support for this by adding a new semi-private helper function,
_g_log_structured_standard(), which only uses varargs for the message
format and its arguments, and uses fixed arguments for the other fields.
This is then converted to a set of GLogFields and passed to
g_log_structured() as normal.
Support for -Wformat when compiling *without* G_LOG_USE_STRUCTURED was
never broken.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793074
Some of the documentation linked to information about G_DEBUG already,
but most of it didn’t, and there were no examples. People need obvious
examples.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790157
Certain compilers warn about unused functions if they are declared in
the header but are not inline. We require `static inline` support from
all compilers now.
Typically, this code will not be used, as the compilers we care about
implement vararg macro support; but this code path can still be hit on
some compilers (probably; unverified).
(Commit message by Philip Withnall.)
https://bugzilla.gnome.org/show_bug.cgi?id=483341
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
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
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 ...
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
Its documentation mentions that it logs a 'critical warning', but since
the macro implementation calls g_warn_message(), it does not log a
critical message, but a regular warning.
This reverts commit 662bf991c08b16dea8a36026243b311f6cdb17f1. It is not
a straight up revert because the old commit involved various long since
removed ChangeLog files and we'd end up mudding the patch.
The system_header GCC pragma is breaking warnings in the various
g_return_* macros; GCC stopped warning when using a macro with a return
value in a function that returns void, as well as when using a macro
with no return value in a function that has a non-void return value.
Suppressing this kind of warnings is not a good idea.
Other compilers are unaffected, even ones like Clang with a GCC
compatibility layer.
Given the fact that the original commit was added 14 years ago as a
workaround in the old days of GTK+ 1.2, I think it's safe to drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=753310
In particular, it is not incorrect to g_return_if_fail (..., FALSE)
in a function returning a "success" gboolean and a GError: "failure to
meet the preconditions is an error" takes precedence over the
GError documentation's guarantee that the error will be set on failure.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=660809
Reviewed-by: Emmanuele Bassi
...Under various compilers when !G_DISABLE_CHECKS. Previously, the
messages that are logged differ depending whether GLib was built with GCC
or not. To simplify test cases, make all builds use a single output format
for g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), and
g_return_val_if_reached(), by using the GCC-style format and replaceing
__PRETTY_FUNCTION__ with G_STRFUNC, so that it will work across various
compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
The clang code analyzer needs to know that functions like g_error
g_critical an g_return_if_fail should be seen by the analyzer in the
same way as g_assert(). That is the analyzer should think they are
fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=700268
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
If gtk-doc sees 'Returns ...' written in the text of the documentation
for a macro, it thinks that you are talking about the return value.
Avoid doing that and use 'Returns:' explicitly if we mean to.
2008-05-05 Michael Natterer <mitch@imendio.com>
* glib/glib.h: #define __GLIB_H_INSIDE__ around including
everything.
* glib/*.h: check for that define instead of __G_LIB_H__ if
G_DISABLE_SINGLE_INCLUDES is defined.
* glib/gdatasetprivate.h: #include <glib.h> instead of
<glib/gdataset.h>
svn path=/trunk/; revision=6875
2008-03-14 Michael Natterer <mitch@imendio.com>
* glib/*.h: make it possible to disable single-file includes by
defining G_DISABLE_SINGLE_INCLUDES when building against GLib.
Approved by Tim Janik.
* glib/glib.h: include <glib/gslice.h>.
* glib/gi18n.h
* glib/gi18n-lib.h
* glib/gprintf.h: include <glib.h> so the above works when these
files are included without including <glib.h> first.
svn path=/trunk/; revision=6713
