GDate.dmy is a 1-bit bitfield which is treated as a boolean. However,
it’s still an integer, and we can’t really treat it like a gboolean
because it’s a bitfield. Make the comparisons with it explicitly compare
integers, rather than implicitly, to make it more obvious that it is
actually an integer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=335731
These turn undefined or hard-to-detect misbehaviour into a well-defined
critical warning and early return.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=335731
It’s possible to get a -Wmaybe-uninitialized warning out of this code
with some GCC versions. Rework the code to avoid needing the conditional
free.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728108
This was a small leak of a GDateTime instance from an internal helper
function, which was using it to calculate week numbers, and then forgot
to free it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795165
This is a non-trivial accessor which gets the identifier string used to
create the GTimeZone — unless the string passed to g_time_zone_new() was
invalid, in which case the identifier will be `UTC`.
Implementing this required reworking how timezone information was loaded
so that the tz->name is always set at the same time as tz->t_info, so
they are in sync. Previously, the tz->name was unconditionally set to
whatever was passed to g_time_zone_new(), and then not updated if the
tz->t_info was eventually set to the default UTC information.
This includes tests for the new g_time_zone_get_identifier() API, and
for the g_date_time_get_timezone() API added in the previous commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795165
While 333 runs is very likely to reproduce the bug, Milan has previously
reproduced it with as few as 9 runs. Since this test will be run by the
CI machinery quite often, a lower number of runs each CI run will still
probably catch any regressions over time.
This reduces the total test runtime from 33s to 2s.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
When using g_network_monitor_get_default() from another thread, it’s
possible for network-changed events to be processed after an instance of
GNetworkMonitor has been disposed, causing use-after-free problems.
Fix that by moving some of the initialisation into the GInitable.init()
chain, rather than in a main context idle callback.
This includes a unit test which probabilistically reproduces the bug
(but can’t do so deterministically due to it being a race condition).
Commit amended by Philip Withnall <withnall@endlessm.com> before
pushing.
https://bugzilla.gnome.org/show_bug.cgi?id=793727
gdatetime testcase uses glib (which uses libintl), but *alsi* calls
libintl functions on its own, as part of the testing process.
Therefore it must be linked to libintl like any other program that
uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=794556
We do not need to use FindFirstFileW() to get a reparse tag if the
file that is being examined is not a reparse point.
This is a quick and relatively painless fix for the fact that
FindFirstFileW() fails on root directories. Since root directories
are unlikely to be reparse points (is it even possible?), not using
this function on non-reparse-points just sidesteps the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=795153
If a handle was obtained from a fd that we got from up the stack,
we shouldn't call CloseHandle() on it in case of an error.
This is a bug. Luckily, it happens only on the error codepath, so,
hopefully, no one had hit it yet.
Spotted while running valgrind on gsettings-test, as per the previous
commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
When using g_settings_bind(), if a range binding triggers a range check
failure, g_settings_binding_property_changed() will return early, but it
won't cleanup properly causing some leaks. The binding will also still
be marked as 'running', which causes an assertion failure when trying to
free it:
"g_settings_binding_free: assertion failed: (!binding->running)"
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794805
There is no transfer annotation that can express transfer semantics of
g_object_new_with_properties in general. When GInitiallyUnowned object
is constructed the introspection data will be incorrect.
Mark it with skip annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=795025
There's a race condition somewhere in GTestDBus that can result in
the next test being started at a time when g_bus_get() would still
return the connection that is in the process of closing. This can
be reproduced reasonably reliably by running the gapplication test
10K times in a loop.
Instead of relying on waiting for the weak reference to be released,
we can force the issue by clearing it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768996
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894677
This adds a null notification backend implementation for win32, purely
to avoid crashes due to a missing backend when applications use
GNotification. This backend does nothing except print a warning when a
notification is supposed to be emitted.
In future, it can be expanded to use win32 API to present toaster
notifications appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776583
If glib-networking is installed and built with libproxy support, this
test will use it. If a proxy is set in the environment, we might get
correctly told to go through it for certain accesses. However, this isn't
going to work, because the testsuite monkeys with the network monitor to
tell it that all addresses - including the proxy - aren't reachable.
We're trying to check if adding networks to a GNetworkMonitor works in
general. Proxies just get in the way here, so let's use the built in
dummy proxy resolver which just tells us that all URLs are directly
accessible.
https://bugzilla.gnome.org/show_bug.cgi?id=794801
Explain why we say "See new_stateful()" (although it's pretty obvious).
Drop a redundant copy of the argument description in the body text.
Add a # to the GVariant type name so that we can have a nice link.
https://bugzilla.gnome.org/show_bug.cgi?id=795070
If something is nullable, it's always helpful to identify what NULL
means. Also, this is not the parameter for the .activate() vfunc, as we
take that over: rather, it is the parameter for the ::activate signal.
https://bugzilla.gnome.org/show_bug.cgi?id=795070
The base Fedora image we use for our CI does not always have an updated
Meson package to fit our requirements. Let's install Meson using
Python's pip instead.
Accurate G_HAVE_GNUC_VISIBILITY is needed to correctly
define G_GNUC_INTERNAL later on. Autotools did that,
meson currently doesn't and opts to just set
G_HAVE_GNUC_VISIBILITY to 1 for all compilers except MSVC.
This leads to MinGW GCC having G_HAVE_GNUC_VISIBILITY=1,
which results in G_GNUC_INTERNAL being defined to
__attribute__((visibility("hidden"))), which is not supported.
Because cc.compiles() does not support override_options or
anything like that, we just feed it '-Werror' as-is, since
MSVC is known as not supporting visibility attributes anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=794636
This is a bit awkward. A more elegant solution would have
ignored *all* headers and then *un-ignored* some of them
if some conditions were met.
Sadly, we cannot really ignore all headers and then "unignore"
them: that's not how arrays in Meson work.
https://bugzilla.gnome.org/show_bug.cgi?id=794557
GCC has built-ins for these functions, which might give a compile-only
test an impression that the functions are actually present in the C runtime.
Use a linked test to be sure.
Specifically, both functions are missing on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=794555
The `mount_monitor` variable is only set if the boolean
`with_mount_monitor` variable is set to TRUE, but the compiler does not
know that, so it'll warn when calling `g_clear_object()` even if the
clearing operation is gated with the same boolean.
Initializing with NULL does not cost us anything, and eliminates a
conditional branch.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
The g_auto macros are available only with GCC-compatible compilers on
Unix, but having __attribute__((cleanup)) is not part of our toolchain
requirements, so we shouldn't use it — even if we are building on
Unix-compatible systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794732
This pollutes the reserved compiler namespace and breaks applications
trying to do their own feature detection. For instance, this falsely
detects that alloca is not a builtin on gcc:
#include <glib.h>
#if defined(__has_builtin)
# if !__has_builtin(alloca)
# error "wtf glib?"
# endif
#else
/* version-checking to determine alloca existence */
#endif
Instead, define our own g_macro__has_* versions that have the
behaviour that we need.
https://bugzilla.gnome.org/show_bug.cgi?id=794635
Some very odd systems have the functions to initialise and destroy a
struct __res_state, but apparently not to do a DNS query using it. Fix
the compilation on those systems.
https://bugzilla.gnome.org/show_bug.cgi?id=794606
