It was previously only enabled (by default) on macOS, which led to
code being committed which triggered warnings, as that CI job is not
always run.
Avoid that risk by always enabling the warning.
The reasoning for using this warning is that explicit initialisation is
clearer than implicit. We also want to support GLib’s public headers
being used in projects which build with
`-Werror=missing-field-initializers`, but can’t easily enable the
warning for our public headers but not our internal code. So enable it
everywhere.
Make it a warning rather than an error, as there’s a risk that system
header changes will trigger it in distro release builds, which would
cause false build failures. By making it a warning, GLib developers can
build with `-Werror` and promote it to an error, while distros can
choose not to.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2812
This should quell a scan-build error about dereferencing `member_info`
when it’s `NULL` at the end of the function, due to having zero
iterations of the `for` loop.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should quell some scan-build warnings about code breaking after
returning from mem_error() in a weird state.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
How the assertions handled the case of `buf != NULL && count == -1` and
`buf == NULL && count == -1` were a bit fragile.
In the former case, the `strlen (buf)` was assigned to `count`, which is
signed. If, somehow, `buf` was huge, `count` would end up wrapping
around to a negative number. Avoid that by assigning directly to
`count_unsigned`.
In the latter case, `count_unsigned` would be set to `-1` which would
wrap around. The error would then be caught by the precondition on `buf
!= NULL`, but it seems like that could have been a happy accident rather
than something intentional. Change it to an explicit precondition which
only allows `buf == NULL` iff `count == 0`.
Spotted while reading through static analysis issues, although the
analyser didn’t explicitly flag this up as an issue.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It should be enabled in all builds, not just CI builds. Otherwise
developers might miss it locally.
This updates commit f11b96f255.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should fix the Coverity build, which is currently broken:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389979
```
../gmodule/gmodule-deprecated.c:8: error: "GLIB_DISABLE_DEPRECATION_WARNINGS" redefined [-Werror]
8 | #define GLIB_DISABLE_DEPRECATION_WARNINGS
|
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead, iterate the `GMainContext` directly. This allows tests on
asynchronously returned values to be done in the actual test function,
rather than a callback, which should make the tests a little clearer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the code a little easier to understand and allows the kernel
a little bit more leeway in scheduling the callback, which is fine
because we don’t need high accuracy here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`g_notification_backend_new_default()` adds a reference on
`backend->dbus_connection` (if non-`NULL`), but nothing ever unreffed
that.
Fix that by adding a dispose method.
In practice this is not really a problem, because the notification
backend is held alive by a `GApplication`, which lives as long as the
process. It’ll be a problem if someone is to ever add unit tests for
`GNotificationBackend`s though. So let’s fix it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add a few missing introspection annotations too.
This doesn’t change any of the ownership handling behaviour, just
documents what’s there. What’s there seems to be correct, to the extent
that I can see.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code is correct, but from a quick read-through it wasn’t entirely
clear to me how it handled floating `GVariant`s in object state or the
`parameter` argument.
Add an assertion and some comments to hopefully clarify things a little.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Do not use can_run_host_binaries() as it returns true even though
custom_target() does not currently correctly wrap target-built
tool binaries with exe_wrapper so they can be run on the host.
See https://github.com/mesonbuild/meson/issues/11029
Otherwise this test will succeed at build-time, but will fail when run
as an as-installed test via ginsttest-runner.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Building GLib 2.75.0 on Linux adds various inotify-related internal
symbols to the ABI, which doesn't seem to have been intentional.
I went through the other libraries in the build system, and it looks
as though the BSD kqueue backend would have the same problem.
GNU symbol visibility probably doesn't do anything for gio/win32, but
for completeness I've set that to use hidden symbols too, on the basis
that it'll be easier to get this right if we're consistent.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2811
Signed-off-by: Simon McVittie <smcv@collabora.com>
The macOS CI builds with -Werror=missing-field-initializers by default,
making incomplete initializers a compile-time error (even though their
meaning is well-defined: missing fields are initialized as if with
.field = 0).
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2812
Signed-off-by: Simon McVittie <smcv@collabora.com>
It’s deprecated, but the big red 0/0/0 line for the `glib/gthread`
directory in the lcov output for GLib is driving me nuts.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The fuzz tests are run on a separate CI system, and we don’t care what
their code coverage is. The only reason they’re run on our CI systems at
all is as a smokecheck. They are not unit tests that we want to check
are running every line.
Similarly, exclude copylibs/subprojects as GLib is not responsible for
testing them. They have (or should have) their own unit tests and code
coverage metrics in their upstreams.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This typically indicates a bug in the program, where a GTask has been
created, but a bug in the control flow has caused it to not return a
value.
There is one situation where it might be legitimate to finalise a GTask
without returning: if an error happens in your *_async() start function
after you’ve created a GTask, but before the async operation returns to
the main loop; and you report the error using g_task_report_*error()
rather than reporting it using the newly constructed GTask.
Another situation is where you are just using GTask as a convenient way
to move some work to another thread, without the complexity of creating
and running your own thread pool. GDBus does this with
g_dbus_interface_method_dispatch_helper(), for example.
In most other cases, it’s a bug. Emit a debug message about it, but not
a full-blown warning, as that would create noise in the legitimate
cases.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This can be used to mark entire types as deprecated,
and trigger a warning when they are instantiated
and `G_ENABLE_DIAGNOSTIC=1` is set in the environment.
There's currently no convenient macros for defining
types with the new flag, but you can do:
```c
_G_DEFINE_TYPE_EXTENDED_BEGIN (GtkAppChooserWidget,
gtk_app_chooser_widget,
GTK_TYPE_WIDGET,
G_TYPE_FLAG_DEPRECATED)
...
_G_DEFINE_TYPE_EXTENDED_END ()
```
Includes a unit test by Philip Withnall.
the gio dbus codegen test has 10 test cases in it.
Each test case is given 100 seconds to complete.
That is far longer than they should need.
Furthermore, the entire test is only given 60s
to complete.
This commit makes the internal timeout more consistent
with the external timeout, by giving each of the 10
test cases 6 seconds instead of 100s.
