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
Now that the old logging API forwards through to the new structured
logging API, we don’t need to check the level or domain of a message
against INFO_LEVELS or G_MESSAGES_DEBUG — just pass it straight through
to the new structured logging API writer function.
https://bugzilla.gnome.org/show_bug.cgi?id=775879
In my previous attempt to improve colored console output on Windows, we
called GetFileInformationByHandleEx() directly if we target Vista or
later, but the check macro for doing so via LoadLibrary() had a typo. Fix
this by correcting the check macro.
Pointed out by Ignacio Casal Quinteiro.
... when tty terminal emulators (such as mintty) are used. This support
is however for Vista and later, so use of such terminals should have
support for ANSI color codes in their outputs, even on Windows 7/8/8.1/
https://bugzilla.gnome.org/show_bug.cgi?id=775468
Windows 10 begins to support color output on the console using ANSI
codes, but a few extra steps are required for this support, so we cannot
just use isatty() and expect colors to work in the outputs.
Instead, we use still use isatty() from the Windows CRT, and then enable
ENABLE_VIRTUAL_TERMINAL_PROCESSING if it returns true.
Also make the invalid parameter handler shared between gmessages.c and
gspawn-win32-helper.c, since it is basically intended to be a no-op stub.
https://bugzilla.gnome.org/show_bug.cgi?id=775468
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
A windows application compiled with -Wl,--subsystem,windows has no
console attached. When started from the start menu for ex, it will crash
when a function attempt to use g_log:
#10 0x00a21b26 in g_logv (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed", args=0x28f2bc "PG"")
#11 0x00a21bb1 in g_log (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed") at gmessages.c:1337
#12 0x00a22bac in g_return_if_fail_warning (log_domain=0xa842e1 <__func__.7668+329> "GLib", pretty_function=0xa84750 <__func__.65002> "g_log_writer_supports_color",
expression=0xa844de <__func__.7668+838> "output_fd >= 0") at gmessages.c:2453
#13 0x00a2239e in g_log_writer_supports_color (output_fd=-2) at gmessages.c:1826
#14 0x00a226ac in g_log_writer_standard_streams (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2254
#15 0x00a2290e in g_log_writer_default (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2357
According to https://msdn.microsoft.com/en-us/library/zs6wbdhx.aspx:
If stdout or stderr is not associated with an output stream (for
example, in a Windows application without a console window), the file
descriptor returned is -2. In previous versions, the file descriptor
returned was -1. This change allows applications to distinguish this
condition from an error.
Check if the stream exists and has an associated descriptor and return
G_LOG_WRITER_UNHANDLED if it's not the case.
Fixes:
https://bugzilla.gnome.org/show_bug.cgi?id=772511
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Ensure that all the old log handler documentation includes
cross-references to a new section about how to enable structured logging
(tl;dr: #define G_LOG_USE_STRUCTURED).
https://bugzilla.gnome.org/show_bug.cgi?id=769785
Give some example log domains, and recommend that G_MESSAGES_DEBUG is
used universally as the way to enable debug output (rather than having a
separate environment variable per library).
https://bugzilla.gnome.org/show_bug.cgi?id=682794
It’s effectively deprecated if G_LOG_USE_STRUCTURED is defined, or if
the structured logging API is used directly. See the documentation for
rationale.
https://bugzilla.gnome.org/show_bug.cgi?id=769486
g_log_writer_is_journald() works out whether the process’ stderr or
stdout are redirected to journald. While the default writer function
uses this in conjunction with g_log_writer_journald(), that does not
always have to be the case — other writer functions might want to always
write to the journal, and never write to stderr (for example).
Consequently, automatically open the journal socket in
writer_journald(), rather than is_journald().
https://bugzilla.gnome.org/show_bug.cgi?id=769507
journald is a part of systemd which is Linux-only at this time, so only
compile the journald items on Linux only, and just return FALSE for
g_log_writer_is_journald() and G_LOG_WRITER_UNHANDLED for
g_log_writer_journald() on non-Linux.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
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
