This is basically glnx_steal_fd() from libglnx. We already had two
private implementations of it in GLib.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The (out caller-allocates) and (out callee-allocates) annotations are
meant for structured or pointer types. Plain old data types are just
regular out parameters and don't need the annotation about who
allocates them.
See: https://gitlab.gnome.org/GNOME/gjs/-/issues/386
1) Check that schedule_call_in_idle code branch of gdbusnamewatching.c
is working to call vanished handler in the thread which had watched the name
2) Check cancellation of vanished handler if the name is unwatched before
vanished callback is dispatched.
Closes#2011
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
After the recent reworking of this code it was possible for `g_close()`
to be called on `fd == -1`, which is invalid. It would have reported an
error, were errors not ignored. So it was harmless, but still best to
fix.
Simplify the error handling by combining both error labels and checking
the state of `fd` dynamically.
Coverity CID: #1450834
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Some versions of compilers inline gobject_init_ctor() and
type_class_init_Wm(), so the existing suppression rules would no longer
match. Try to generalize them to handle these cases.
The variable `gconstructor_code` (which is what’s defined by
`gconstructor_as_data_h`) is not used at all inside
`glib-compile-schemas`.
This looks like a copy/paste error from the build definition for
`glib-compile-resources` below, which does need it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This also gives details of how to report a security issue, including the
key point that merge requests are (unfortunately) not confidential.
Heavily based on the flatpak security policy which just landed:
https://github.com/flatpak/flatpak/blob/master/SECURITY.md
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
In the 2.68 cycle we’d added 3 new enumerator elements. Due to the
preceding commit, they can now be annotated with
`GLIB_AVAILABLE_ENUMERATOR_IN_2_68`, which will make it a bit easier for
third party projects to notice when they’re using these symbols without
having bumped their GLib dependency.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2327
Teach `glib-mkenums` how to parse and ignore:
- `GLIB_AVAILABLE_ENUMERATOR_IN_x_xx`
- `GLIB_DEPRECATED_ENUMERATOR_IN_x_xx`
- `GLIB_DEPRECATED_ENUMERATOR_IN_x_xx_FOR(x)`
Future work could expose the deprecation/availability information as
substitutions in the template file, but this commit does not do that.
It does, however, add some unit tests for the annotations.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2327