Change originally by Piotr in !3257, but the CI has problems with
his name in the author field. Since this change is blocking a release,
I have decided to merge it under my name instead, so that it lands sooner.
In parallel, we are trying to figure out what is broken with the CI so
this does not happen again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s a private API, and is not meant to be exposed in the public API.
Since it’s only used internally within libglib, we don’t have to expose
it in the public symbol table, so drop the decorator.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2876
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
GObject-Introspection seems to become confused by the nested conditional
followed by an `#elif` clause for the outer conditional, and issues
this warning:
.../gtimezone.c:830: mismatched #elif defined (G_OS_WIN32)
Signed-off-by: Simon McVittie <smcv@collabora.com>
GObject-Introspection and gtk-doc both parse C headers using regular
expressions, so they can easily be confused by non-trivial conditions.
GObject-Introspection warns about this:
.../gstrfuncs.h:151: the __GI_SCANNER__ constant should only be used with simple #ifdef or #endif: #if !defined (__GTK_DOC_IGNORE__) && !defined (__GI_SCANNER__)
In this case it's very easy to convert the compound expression into
nesting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The sample code here wasn't a race-free version of the race-susceptible
anti-pattern, because it would have dereferenced a symlink automatically.
Fixes: 293b4923 "Clarify g_file_test() docs about TOCTOU bugs"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The canonical directory separator is a backslash, but some Windows APIs
allow either, interchangeably. Do the same here.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2914
Signed-off-by: Simon McVittie <smcv@collabora.com>
Glib does not yet have a well defined ABI/API for architectures
where gsize != guintptr (e.g. CHERI). To enable working on bringup
for new architectures this assertion can be disabled with
`-DG_ENABLE_EXPERIMENTAL_ABI_COMPILATION`.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2842
[smcv: Apply review comments from pwithnall]
Signed-off-by: Simon McVittie <smcv@collabora.com>
On closer inspection, these are redundant with stricter assertions that I
added in commit bd1e2a98 "glib-init: Statically assert more facts about
standard types", which assert that sizeof (gintptr) == sizeof (void *).
As far as I can tell, a sufficiently pedantic interpretation of Standard
C doesn't actually require (u)intptr_t to be the same size as a pointer:
it only requires that pointers can be losslessly stored in a (u)intptr_t,
which a sufficiently pathological ABI could implement by having (for
example) 32-bit pointers and a 64-bit uintptr_t just to troll us. However,
I'm fairly confident that no practically useful ABI would do this,
and certainly nobody has complained about this assertion since 2020.
Similarly, Standard C might permit an ABI where 64-bit pointers have the
first 32 bits always-zero and therefore storing the remaining bits in a
32-bit uintptr_t is lossless, but again, that would be pathological.
This reverts commit da3fc59544.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Do not use 4-spaces indentation for return and argument descriptions, to
avoid getting rendered as preformatted blocks.
Annotate code examples with their language, for syntax highlighting.
Isolate the first paragraph to give a short description.
Do not show just what not to do: show what to do instead, otherwise
people won't know how to fix their code.
Make sure to link to an explanation of the TOCTOU class of bugs;
Wikipedia is as good a place as any.
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.
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
