`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.
According to the docs, g_slice_free1() is supposed to do nothing if
@mem_block is NULL, but we still try to zero it in case we're using
g_mem_gc_friendly.
So avoid this case.
Closes: #2908
Since commit 45b5a6c0 GSlice is just a wrapper to g_malloc0/g_free, so
there's no point to use a different implementation for UNIXes vs
windows.
This reverts commit 3b7af4dd5d.
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.
If libc supports `free_sized()`, this could mean that freeing slices is
a bit more performant. If not, it falls back to using `free()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If we are sorting something that is a multiple of sizeof(void*), we have
to ensure that we swap one pointer at a time since swapping using
sub-pointer-size stores invalidate the pointers (pointers have a hidden
validity tags that is invalidated when performing non-monotonic
operations such as storing only part of the pointers).
While touching this code also use G_ALIGNOF() instead of a macro that
is generated at configure time.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
We have to ensure that the memory location is sufficiently aligned to
store any object. This unbreaks the code for CHERI where using gsize
results in values that are only aligned to 8 bytes, but we need 16 byte
alignment for pointers. This is fully API/ABI compatible since amount
of padding before the actual allocation does not change for existing
architectures, only for CHERI.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
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>
Since commit 94b658ab4c, gwakeup.c has
started using C99 integer types, but has not included <stdint.h>. This
broke building on GNU/Hurd. Fix this by adding the missing include.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
...much like g_string_free_and_steal () does; by redirecting
g_string_free (_, FALSE) calls (when we can detect them) to
g_string_free_and_steal ().
This relies on some unpretty macros, but should be entirely transparent
to any users of g_string_free (). In particular, the macro only
evaluates its arguments once, no matter which branch ends up being
taken. The ternary operator the macro expands to always gets optimized
out, even at -O0: there is only one call to either g_string_free () or
g_string_free_and_steal () in the compiled code, with no run-time
branching.
Add a test for ensuring this works as expected in C++ too.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
