The following warning is shown, when both g_output_stream_write and
g_output_stream_close fail:
"GError set over the top of a previous GError or uninitialized memory."
Let's clear the error after use.
https://bugzilla.gnome.org/show_bug.cgi?id=786463
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
1 0xb67c43f0 in __GI_abort () at abort.c:89
2 0xb69ee9d8 in _g_log_abort (breakpoint=2, breakpoint@entry=1) at gmessages.c:548
3 0xb69ef692 in g_logv (log_domain=0xb6a1dfc8 "GLib", log_level=-1254563840, log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0xb6a26a48 "%s: assertion '%s' failed", args=..., args@entry=...) at gmessages.c:1357
4 0xb69ef728 in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=0xb6a26a48 "%s: assertion '%s' failed") at gmessages.c:1398
5 0xb69efa5a in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:2687
6 0xb69efe7c in g_log_writer_is_journald (output_fd=-1) at gmessages.c:2122
7 0xb69f02a2 in g_log_writer_default (log_level=G_LOG_LEVEL_CRITICAL, fields=0xbedc9d00, n_fields=4, user_data=0x0) at gmessages.c:2584
8 0xb69ef21a in g_log_structured_array (log_level=G_LOG_LEVEL_CRITICAL, fields=0xbedc9d00, n_fields=4) at gmessages.c:1933
9 0xb69ef47e in g_log_default_handler (log_domain=0xb6a1dfc8 "GLib", log_level=G_LOG_LEVEL_CRITICAL, message=<optimized out>, unused_data=<optimized out>) at gmessages.c:3036
10 0xb69ef5fc in g_logv (log_domain=0xb6a1dfc8 "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0xb6a26a48 "%s: assertion '%s' failed", args=..., args@entry=...) at gmessages.c:1336
11 0xb69ef728 in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=0xb6a26a48 "%s: assertion '%s' failed") at gmessages.c:1398
12 0xb69efa5a in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:2687
If stderr is not associated with an output stream, the fileno(stderr) returned is -1.
So, g_return_if_fail_warning is recursively called and the abort occurs on the second call.
Modified by Philip Withnall to include mention this in the
documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=786452
We want to set _WIN32_WINNT so that functions will be properly found in
the headers, to target the NT6.1+ (Windows 7+) APIs.
Also improve the checks for if_nametoindex() and if_indextoname() on
Windows as they are supported in Windows Vista+, but they have
to be checked by linking against iphlpapi.lib (or -liphlpapi). On other
platforms, they are still checked as they were before.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Instead of hardcoding -DPCRE_STATIC into the CFLAGS of GLib, do the
following on Windows only (since PCRE_STATIC only matters on Windows):
-If there is no installed PCRE, use the included PCRE copy and
enable -DPCRE_STATIC, as we did before.
-If there is a installed PCRE, check whether the PCRE build is a static
or DLL build by checking the linkage against pcre_free() with
PCRE_STATIC defined works. If it does, enable -DPCRE_STATIC.
-On non-Windows builds, do not enable -DPCRE_STATIC
https://bugzilla.gnome.org/show_bug.cgi?id=783270
The HAVE_GOOD_PRINTF config variable determines whether we are able to
use the CRT-supplied *printf() functions directly, by determining whether
the CRT-supplied vsnprintf() and snprintf() functions support C99 well
enough.
This means, we need to build the gnulib subdir as a static lib in GLib, and use
the gnulib *printf() functions when:
-We are on Windows
-The CRT's vsnprintf() and snprintf() is not sufficiently C99-compliant.
This will fix the problem when the *printf() functions cause a CRT
abort() call on pre-2015 Visual Studio builds at least, and ensures that
the Visual Studio 2015+ builds will pass the printf tests in GLib, since
the *printf() in Visual Studio 2015/2017's CRT does not support the %n
format specifier, nor the positional parameters (which requires
different _*printf_p*() functions), as indicated by
glib/tests/test-printf.c.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Copy the msvc_recommended_pragmas.h helper header when we build for
Windows, so that people developing/using GLib on Windows can make use
of them in Visual Studio, so that unwanted compiler noise can be
filtered out and code with potentially-problematic warnings can be
attended to.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the dependencies' build systems for Visual Studio do not provide a
pkg-config file upon build, so we use find_library() for them when the
corresponding pkg-config files are not found during Visual Studio builds,
so that one will not need to make up pkg-config files for them, which
could be error-prone. These .lib names match the names that are built
with the officially supported build system that is used by their
respective Visual Studio support.
For ZLib, this will make gio-2.0.pc reflect on the zlib .lib based on
what is found, or whether we use the fallback/bundled ZLib, when we
don't have a pkg-config file for ZLib on MSVC. We still need to depend
on Meson to be updated to put the correct link argument for linking ZLib
in the pkg-config case.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Without this, GNU-specific symbols won't be defined and the compiler
check will pass because GCC will assume that you know what you're
doing since it doesn't know what the symbol prototype is and compiler
checks aren't built with -Wall -Werror.
This will then cause a build failure because the wrong prototype will
be used.
Try to get XDG_* environment variables and, if they are available, use their
contents to initialize various directories the same way this happens on *nix.
When these variables are not available, fall back to the W32-specific APIs for
getting directories.
https://bugzilla.gnome.org/show_bug.cgi?id=766358
We use it pretty much everywhere in order to get feature detection, and
that's also what the AC_USE_SYSTEM_EXTENSIONS m4 macro defines in the
Autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=785955
Calling g_variant_get (parameters, "(&s)") when parameters has a
signature other than (s) is considered to be a programming error.
In practice the message bus (dbus-daemon or a reimplementation) should
always send the expected type, but be defensive.
(Modified by Philip Withnall to improve type check.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784392
PulseAudio and LibreOffice are among the services that use this flag.
Refusing to queue for a name lets you do this transaction,
but atomically, avoiding the transient state where you briefly join
the queue and then are given the name when its primary owner drops it:
result = RequestName(name)
if result == IN_QUEUE:
ReleaseName(name)
result = EXISTS
return result
(Modified by Philip Withnall to add documentation.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784392
The implementation passes flags through directly to the RequestName()
call, so if any new values break that equivalence, the implementation
will have to be changed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784392
If no callback is provided, token is never set, but it’s then passed to
g_variant_new_string(), which requires a non-NULL input.
Fix that by moving all the option handling inside the (callback != NULL)
case.
Spotted by Coverity (CID #1378714).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785817
Since --header --body has been deprecated and replaced with --body
--prototypes, the generated body is not wrapped with G_{BEGIN,END}_DECLS
any longer. Projects using C++ break due to that. Automatically wrap
prototypes individually in G_{BEGIN,END}_DECLS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785554
Little did I know when making commit
c257757cf6 that a lot of the output of
glib-compile-schemas is string matched in some of the unit tests. Fix
them to match the updated strings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=695573
