These well-known flags and replies are part of the D-Bus Specification,
and also exist with the same names in libdbus header files.
Moving them into a private header means that unit tests like
gdbus-proxy-threads and gdbus-subscribe don't have to reinvent them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Unlike the various functions to call D-Bus methods, these sort their
arguments in a non-obvious order (bus name, interface, signal, path),
presumably aiming to sort the most-likely-to-be-used arguments first.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These function arguments are arranged in the obvious order from
conceptually largest to smallest: (bus name, path, interface, method).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This test was subscribing to the NameOwnerChanged signal with an
incorrect object path, so the callback would never be called. In this
particular case it doesn't actually matter, because the callback does
nothing anyway (the purpose of this particular test was to test that
the user-data is freed on unsubscription).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Almost identically to the previous commit, fix a similar latent bug in
`g_dbus_connection_export_action_group()`, which was not ready to handle
the fledgling `GActionGroupExporter` being freed early on an error
handling path.
See the previous commit message for details of the approach.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
Fedora 37 is out of support so, as per our policy, update the CI image
to the oldest still-supported release, which is 39.
Update the mingw CI image too, as it’s built on top of the Fedora one.
Update the supported platforms documentation (and fix the Debian version
listed there to match what’s currently in CI, which is up to date).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This latent bug wasn’t triggered until commit 3f30ec86c (or its
cherry-pick onto `glib-2-80`, 747e3af99, which was first released in
2.80.1).
That change means that `g_menu_exporter_free()` is now called on the
registration failure path by `g_dbus_connection_register_object()`
before it returns. The caller then tries to call `g_slice_free()` on the
exporter again. The call to `g_menu_exporter_free()` tries to
dereference/free members of the exporter which it expects to be
initialised — but because this is happening in an error handling path,
they are not initialised.
If it were to get any further, the `g_slice_free()` would then be a
double-free on the exporter allocation.
Fix that by making `g_menu_exporter_free()` robust to some of the
exporter members being `NULL`, and moving some of the initialisation
code higher in `g_dbus_connection_export_menu_model()`, and removing the
duplicate free code on the error handling path.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
gio/glocalfileinfo.c has a struct 'ThumbMD5Context'
that's been unused since
commit d013d46b98 ("Replace the copy-and-paste MD5 digest generation
with GChecksum.")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
The type used when declaring a bitfield member of a struct doesn't
affect the amount of space allocated for it - only whether it's signed
or unsigned. In standard C99 (6.2.7.1), only _Bool, signed int and
unsigned int or typedefs to them are allowed as bitfield types, but GCC
allows other integer types as an extension.
In this case, the GIBaseInfo and GIBaseInfoStack structs are meant to
have identical layout. However, type_is_embedded was declared as an
unsigned bitfield in the former and a uint32_t in the latter. This was
harmless on most platforms because the following member is an aligned
pointer, but (for example) on m68k-linux-gnu pointers only need to be
16-bit aligned, so GCC only allocates 16 bits for the bitfield.
Change the type in the declaration to unsigned int, and add an padding
bitfield following it to ensure there's space for 32 bits on all
platforms in the future.
Signed-off-by: Adam Sampson <ats@offog.org>
GCC 14 now emits this warning with the tests:
```
In file included from ../glib/gthread.h:34,
from ../glib/gasyncqueue.h:34,
from ../glib/glib.h:34,
from ../glib/tests/atomic.c:14:
../glib/tests/atomic.c: In function 'test_types':
../glib/gatomic.h:140:5: error: argument 2 of '__atomic_store' discards 'volatile' qualifier [-Werror=discarded-qualifiers]
140 | __atomic_store (gaps_temp_atomic, &gaps_temp_newval, __ATOMIC_SEQ_CST); \
| ^~~~~~~~~~~~~~
../glib/tests/atomic.c:139:3: note: in expansion of macro 'g_atomic_pointer_set'
139 | g_atomic_pointer_set (&vp_str_vol, NULL);
| ^~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
```
I can’t think of a way to cast around this in the definition of
`g_atomic_pointer_set()` without making the behaviour worse (less type
safe) for modern non-volatile atomic variables.
We would like to strongly nudge users of GLib away from declaring atomic
variables as `volatile`, so letting another compiler warning be emitted
when they do is not the end of the world. As long as it doesn’t stop old
code compiling (without `-Werror`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It's an array containing the list of sanitizers in use, normally it
contains a value, but in some cases may have more than one (e.g.
'address' and 'undefined').
And so use it to avoid repeated checks
In glocalfile we're allocating some temporary strings but we don't free
them on early returns, so free them once done and unset the variables
to prevent them being used incorrectly.
It looks like that finally also valgrind notices the same leaks as
address sanitizer does. It does it more randomly but it still happens,
so better to inform about until #2309 is resolved.
Tests may have runtime dependencies that are related to the typelib
dependencies, so we need to satify them or the tests will fail at
runtime if we're not building their prerequisite for other reasons.
That's saying that the tests are currently failing when explicitly
running as standalone in meson.
Co-Authored-By: Philip Withnall <philip@tecnocode.co.uk>
