Previously it was only being set on non-Windows platforms. For
consistency, always set it on Windows too.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2934
Following on from #2907, set various boolean attributes if they have
been requested, or are known for sure, and their value is `FALSE`.
Previously the `FALSE` value would have been implicitly returned by the
getter function, but now doing that without the attribute being
explicitly set will trigger a critical warning.
*Don’t* set these attributes if their value is unknown or there was an
error querying it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2934
This fixes:
| ../glib-2.75.3/gio/tests/cxx.cpp: In function 'int main(int, char**)':
| ../glib-2.75.3/gio/tests/cxx.cpp:61:15: error: missing sentinel in function call [-Werror=format=]
| 61 | g_test_init (&argc, &argv, NULL);
if built with musl libc
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Add a missing steal call in `schedule_method_call()`. This introduces no
functional changes, but documents the ownership transfer more clearly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2924
This `GDBusMethodInvocation` may be shared across threads, with no
guarantee on the strong ref in one thread outlasting any refs in other
threads — so it needs a ref in this helper struct.
This should fix a use-after-free where the `GDBusMethodInvocation` is
freed from `g_value_unset()` after `g_signal_emit()` returns in
`dispatch_in_thread_func()` in one thread; but then dereferenced again
in `g_source_destroy_internal()` from another thread.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2924
The `GDBusInterfaceSkeleton` is already stored as the source object of
the `GTask` here, with a strong reference.
Storing it again in the task’s data struct is redundant, and makes it
look like the `GDBusInterfaceSkeleton` is being used without holding a
strong reference. (There’s not actually a bug there though: the strong
reference from the `GTask` outlives the data struct, so is sufficient.)
Remove the unnecessary helper struct member to clarify the code a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2924
This introduces no functional changes; just made it while trying to
debug issue #2925.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2925
Otherwise it’s possible for it to hang around in the `GMainContext`
after the “send message” operation has finished. In the best case, this
will cause the `GTask` and `GDBusMessage` to not be freed when the
calling code expects. In the worst case, it could cause use-after-free
problems if it derefs allocations which have since been freed.
I have not seen either of these problems in practice, but it would be
best for the code to eliminate the risk of them altogether by explicitly
destroying the source when the operation is finished.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2925
mkstemp-like family of functions also use g_open () under the hood so
they should pass the O_CLOEXEC flag there for race-free setting of the
close-on-exec flag.
setmntent () call uses the same mode flag set as fopen (), so it should
also include the "e" mode flag for race-free setting of the close-on-exec
flag.
All Unix CRTs examined: glibc, musl, BSDs, Apple libc, Android bionic
ignore unknown fopen () mode flags, so this flag can be added
unconditionally for Unix builds.
Only Windows CRT is intolerant of these, so the single case in
g_dbus_address_connect () where the fopen () call is shared between Unix
and Windows needs appropriate platform-specific handling.
Skipped the call sites in libcharset and xdgmime copylibs.
The `equal_func` closure can already have all required information
available without the item, and passing the item via the closure instead
of an explicit parameter is more natural for languages that have a
concept of closures that can capture variables.
Otherwise, the content of the buffer is thrown away when switching
from reading via a GDataInputStream to unbuffered reads when waiting
for the "BEGIN" line.
(The code already tried to protect against over-reading like this by
using unbuffered reads for the last few lines of the auth protocol,
but it might already be too late at that point. The buffer of the
GDataInputStream might already contain the "BEGIN" line for example.)
This matters when connecting a sd-bus client directly to a GDBus
client. A sd-bus client optimistically sends the whole auth
conversation in one go without waiting for intermediate replies. This
is done to improve performance for the many short-lived connections
that are typically made.
This reverts commit 27bee8fe5d.
Inevitably, despite testing the CI multiple times before merging commit
27bee8fe, the CI is now failing again in the `socket` test due to (what
I continue to assume is) the kernel regression:
https://gitlab.gnome.org/martinpitt/glib/-/jobs/2585332
In order to unblock development on `main` expediently, I guess I’ll just
revert the revert.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Reopens: #2879
It’s not meant to be exposed publicly yet (we’re not ready to stabilise
it), but it was incorrectly decorated with `GLIB_AVAILABLE_IN_2_76`.
We can’t remove the decorator and use it that way, as it’s called in
libgio, so we have to expose it using `GLIB_PRIVATE_CALL()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2876
Don’t just set them when they’re true and rely on their non-presence
being evaluated to `FALSE`. That means that they erroneously don’t get
returned in `g_file_info_list_attributes()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
`g_file_info_get_is_hidden()` should not be called without checking the
attribute is set first, just as with the calls higher up in this code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
As documented in a previous commit, these functions should not be called
without the right attributes being present in the `GFileInfo`. Add
critical warnings to make this more obvious.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
It doesn’t make sense to (for example) call `g_file_info_get_name()` if
the `GFileInfo` doesn’t contain `G_FILE_ATTRIBUTE_STANDARD_NAME`, given
that building the `GFileInfo` is typically a static process and entirely
under the control of the programmer.
By being this restrictive, we avoid having to return ‘unknown’ values
for some of these standard APIs, particularly the numeric ones such as
`g_file_info_get_size()`. If APIs like that were to work correctly in
the face of a `GFileInfo` without `G_FILE_ATTRIBUTE_STANDARD_SIZE`
specified, they’d have to be able to return a value to indicate the
attribute is missing. Returning `0` or `G_MAXSIZE` to indicate that
would be ambiguous.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
Since gmodule-visibility.h is now a custom target and produced at
buildtime, it might not always exist in time for use in other source
files. This was the case for gio-inotify.
Add it as an additional source file to ensure in-time generation.
Currently, inbuf_size and outbuf_size are not documented as not
nullable, but they are expected to be so, which might lead to unexpected
crashes. Moreover, outbuf itself is also expected to not be null, so
this commit adds the appropriate GI annotations and early returns on
failed preconditions.
LLVM objcopy's --strip-all is more aggressive that GNU objcopy --strip-all
and will remove everything that is not actually used. In this case we
see the following error:
`error: 'gio/tests/test_resources.o': Symbol table has link index of 5 which is not a valid index`
Fix this by only removing debug symbols instead of all unused symbols and
sections.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
Unlike GNU ld which has a default target architecture, ld.lld is always a
cross-linker and has the same behaviour for all targets. If you don't tell
ld.lld what the target architecture is it can't infer the right ELF flags
for the resulting object file.
```
$ ~/cheri/output/sdk/bin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
LLD 14.0.0 (compatible with GNU linkers)
ld: error: target emulation unknown: -m or at least one .o file required
```
As you can see from the error message it can't infer the target
architecture (you need a least one valid .o file or the -m flag).
If you use the compiler instead of directly invoking the linker it will
pass the appropriate flags:
```
$ ~/cheri/output/sdk/bin/clang -r -Wl,-b,binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
clang version 14.0.0 (https://github.com/CTSRD-CHERI/llvm-project.git ff66b683475fc44355b2010dbcbe1202d785e6f8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/alexrichardson/cheri/output/sdk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/home/alexrichardson/cheri/output/sdk/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o gio/tests/test_resources.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/alexrichardson/cheri/output/sdk/bin/../lib -L/lib -L/usr/lib -r -b binary gio/tests/test5.gresource
❯ file gio/tests/test_resources.o
gio/tests/test_resources.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
```
This works for most architectures, but ones that need additional metadata
sections to encode the used ABI, etc. will require a different approach
using .incbin. However, that is a change for another MR.
Partially fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
In case the OS does not support epoll and kqueue, we get the warning:
gio/tests/pollable.c: In function ‘test_pollable_unix_nulldev’:
gio/tests/pollable.c:266:7: warning: unused variable ‘fd’
[-Wunused-variable]
266 | int fd;
Get rid of it.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Now that there is g_string_free_and_steal (), we can use it instead of
the older g_string_free (_, FALSE). Make sure to use its return value
while doing so, as opposed to manually accessing string->str, to avoid
compiler warnings and make the intent more explicit.
This is all done in preparation for making g_string_free (_, FALSE) warn
on unused return value much like g_string_free_and_steal (), which will
happen in the next commit.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
