They were mixing up `(optional)` and `(nullable)`, and didn’t correctly
annotate the arguments as `(inout)` or `(transfer full)`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2793
We need to ensure that all the expected macros and utilities are working
with all the supported C standards, so just repeat the tests with all
the ones the compiler supports.
We defined G_NO_RETURN as [[noreturn]] in the C++ case, but only after
trying the __attribute__ syntax, so it was never used in GNUC compatible
compilers.
Give it priority instead when supporting a C++11 compiler and onwards.
As per this we need to adapt the code in the places where it was not
properly used (leading to compilation warnings).
It sometimes fails under valgrind, and is pointless: if the test is
wedged, it’s better to catch that with the timeout at the level of
`meson test`, which can be tailored (using `-t`) to the test environment
and wrapper.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2961#note_1600072
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since it’s now always called the same way after safe_fdwalk() has been
called. This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This thread is created once during the process’ lifetime and cannot be
destroyed and recreated, as the thread scheduler settings might have
changed since then.
Mark the leak as explicit, mostly for documentation purposes — but it
might quieten some static analysers.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474614
Since commit 2f9e6e977a, `count` has been used here incorrectly: after
`count_unsigned` is initialised, `count` should no longer be used as it
might be unhelpfully negative.
Fix this to correctly use `count_unsigned`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In `safe_closefrom()`, we thought it would be OK to assert that an FD
being closed is valid, when using `safe_fdwalk()`, as it only walks over
known-valid FDs.
However, there is a situation where that might not be true: the program
is being run under valgrind. Valgrind opens some FDs for its own use
which are ≥1024, and it emulates a lowered soft limit on FDs. So if we
were to use `safe_fdwalk_with_invalid_fds()` it would see the lowered
soft limit and not try to close valgrind’s internal FDs.
However, `safe_fdwalk()` looks at `/proc`, which valgrind does not emulate,
so it sees the secret valgrind internal FDs, and then tries to close them.
Valgrind doesn’t like this, prints ‘Warning: invalid file descriptor
1024 in syscall close()’ and returns `EBADF`. That return value
causes `g_close()` to warn about faulty FD refcounting, and that causes
unit test failures.
Fix that by relaxing our assumptions about FD validity: use
the `close_func_with_invalid_fds()` call back for closing FDs
from `safe_fdwalk()`, rather than using `close_func()`. That will
ignore `EBADF` return values.
This should fix valgrind failures like this one:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389977
Related prior art: https://bugs.freedesktop.org/show_bug.cgi?id=99839
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
Sadly, in C++ there's not an universal way to get what language standard
is used to compile GLib-based programs, in fact while most compilers
relies on `__cplusplus`, MSVC is defining that, but it does not use it
to expose such information (unless `/Zc:__cplusplus` arg is used).
On the other side, MSVC reports the language standard via _MSVC_LANG [1].
This complication makes us defining some macros in a very complex way
(such as glib_typeof()), because we need to perform many checks just to
understand if a C++ compiler is used and what standard is expecting.
To avoid this, define multiple macros that can be used to figure out
what C++ standard is being used.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
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>
