It’s a false positive, but points to a slightly unnecessary use of a
global variable to store something which could be computed per-test.
scan-build thought that arrays of size `n_handlers` could have
uninitialised values accessed in them if `n_handlers` were to change
value part-way through a test (which it didn’t).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
These are typically files generated by the gobject-introspection dumper,
which we don’t want to scan as they are not part of GLib’s runtime code.
For example:
```
/builds/GNOME/glib/_scan_build/meson-private/tmpr3jwvyib/tmp-introspect5dmnb_je/GObject-2.0.c:799:27: warning: Access to field 'message' results in a dereference of a null pointer (loaded from variable 'error') [core.NullDereference]
799 | g_printerr ("%s\n", error->message);
| ^~~~~~~~~~~~~~
1 warning generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes commit 93271385f9.
Previously the `before_script` from `.build-linux` was used in whole for
these two jobs, but since the `.build-gobject-introspection` template
was also added, the `before_script`s from the two templates need to be
explicitly combined.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3458
Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the
glib Meson policy says we can update. Update the minimum only as far as
1.4.0 because we don't yet have a need for 1.5.0.
This allows us to:
- Use file.full_path() to avoid deprecation warnings on str.format(file).
- Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC.
Update all the CI builds to use the latest 1.4.x patch release, 1.4.2.
The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be
broken for now.
Similarly, the macOS build will not work unless `-Dc_std=gnu99` is
specified at configure time, due to
https://github.com/mesonbuild/meson/issues/13639.
The WSAEnumNetworkEvents API is called every time the socket
needs to be checked for status changes. Doing this in an application
with several sockets could generate a high cpu usage since
this call is done for each socket at each iteration of the main loop.
Since there is also a WSAEvent that gets signaled when there is
a change in the status of the socket, checking its status and
calling the WSAEnumNetworkEvents API only if the event is signaled,
can reduce the overall cpu usage.
The value returned when generating a collation key is an opaque binary
blob that is only meant to be used for byte-wise comparisons; we should
not imply it's a nul-terminated, UTF-8 string.
This is especially true for language bindings that try to convert C
strings returned by GLib into UTF-8 encoded strings.
Ideally, the collation functions should return a byte array, but the
closest thing we have is the OS native encoding type that we use for
paths and environment variables.
See: https://github.com/gtk-rs/gtk-rs-core/issues/1504
