Calling g_signal_handlers_block/unblock/disconnect_matched with only G_SIGNAL_MATCH_ID
do not match any handlers and return 0.
Fixes: #2980
Signed-off-by: Przemyslaw Gorszkowski <pgorszkowski@igalia.com>
The use of ‘OR’ in the existing documentation suggests that the matching
is disjunctive, but it’s actually conjunctive. Clarify that in the
documentation and add a test.
Spotted while reviewing
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3376.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The documentation previously implicitly said in a few places that
interfaces are classed, but reading through the implementation of
`GType`, I don’t think they are. If they were, the registration of the
fundamental `G_TYPE_INTERFACE` in `gobject_init()` would specify
`G_TYPE_FLAG_CLASSED`. It only specifies `G_TYPE_FLAG_DERIVABLE`.
I think this makes sense, because you can’t subclass an interface.
Subclassing is a key property of being classed.
Tweak the `GType` tutorial to remove that implicit statement, and expand
the documentation for `G_TYPE_IS_CLASSED`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #252
‘returns TRUE on success’ is misleading for a lot of these macros, as
they are checking whether a type has a certain property. Such a check
could be successful but return `FALSE`, by the normal meaning of the
word ‘success’.
Instead, reword the docs to spell out when `TRUE` will be returned.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The generated gir file marks the size parameter as "out" by default. This is wrong in the context of a caller allocated buffer with a given size. Explicitly marking the size parameter as (in) fixes the issue.
See issue GNOME/glib#2861. Even though (hopefully!) few people are
actually running kernels this old, some build frameworks use very old
kernel headers to try to maximize the portability of their binary
artifacts.
As explained in the previous commit, GNU Coreutils 9.2 changes the behaviour
of `du --bytes` to only count regular files and symlinks.
The previous commit makes the test pass with GNU Coreutils >=9.2, but the
machine running the tests may have an older version, or perhaps even a
reimplementation such as uutils. So we can't rely on the size returned by `du`
to be the consistent across systems any more.
However, the plus side of the new behaviour is that the size reported by `du`
/ `G_FILE_MEASURE_APPARENT_SIZE` is now well-defined across filesystems
(as the sum of the sizes of regular files & symlinks), so we can hardcode it.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2965
Since GNU Coreutils 9.2 (commit 110bcd28386b1f47a4cd876098acb708fdcbbb25),
`du --apparent-size` (including `du --bytes`) no longer counts all kinds of
files (directories, FIFOs, etc.), but only those for which `st_size` in
`struct stat` is defined by POSIX, namely regular files and symlinks
(and also rarely supported memory objects).
This aligns the behaviour of GLib's `G_FILE_MEASURE_APPARENT_SIZE` flag
with the new GNU Coreutils `du` and correct POSIX use.
Note that this may be a breaking change for some uses.
Link: https://lists.gnu.org/archive/html/bug-coreutils/2023-03/msg00007.html
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2965
Warn when the boolean return isn't used, since we may not initialize
the out arguments in the FALSE case. Update all internal callers to
use the return value. They were already safe, but users outside GLib
may not be.
Correct the info on G_PLATFORM_WIN32, now that we only define it when
GLib is built for native Windows, not Cygwin. Make it clear that it
should not be used to check for conditional compilation for Cygwin
builds of GLib.
clang++ says it supports _Static_assert but then will
complain that it's a C11 extension and that you should not use
it in C++ code (which imho is fair enough)
So try to detect a C++ compiler first and then the C compiler,
similarly to what is done for the G_NORETURN case
Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
proxy-libintl defines ngettext() as a define in the header that points
to the actual symbol in the library which is g_libintl_ngettext().
Same with bind_textdomain_codeset().
Create the wakeup pipe using the `O_NONBLOCK` flag for `pipe2()`, where
possible.
This saves a couple of `fcntl()` syscalls every time a wakeup pipe is
created, which is at least once per `GMainContext`.
This uses the `O_NONBLOCK` support added to `g_unix_open_pipe()` in the
previous commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Add support for it, but don’t use it anywhere yet — this is an API
addition, but currently doesn’t cause any functional changes. It’ll be
used in the next commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `inotify_init1()` API has supported this flag for a long time
(possibly since it was first introduced, although I haven’t bothered
doing the archaeology).
This saves a syscall when first connecting to inotify.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
