Once the task is completed (and `g_task_return_*()` has been called),
the task is no longer needed. It would make more sense to unref it in
`complete_connection_with_error()`, where `g_task_return_*()` is called,
but that complicates other call sites significantly, so I didn’t do it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3184
Some of these are properties of a Standard C or POSIX platform that
are true by definition and checked for completeness (for example intptr_t
is defined to be signed, and uintptr_t unsigned), while others are
checking that GLib's type detection has been done correctly.
Signed-off-by: Simon McVittie <smcv@debian.org>
As a special case, keep the historical behaviour of treating gchar
as being signed, both on platforms where it is genuinely signed (for
example x86 Linux) and where it is unsigned (for example ARM, s390x
and PowerPC Linux). Changing gchar to use INTEGER_ALIAS would have a
regression risk, so if we want to do that, it should be as a separate
change.
No functional change intended.
Signed-off-by: Simon McVittie <smcv@debian.org>
It’s currently completely untested. Let’s add a few basic tests so that
adding more tests in future is easier.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In macOS compilation fails with the following error:
```
In file included from ../girepository/tests/autoptr.c:23:
../girepository/girffi.h:30:10: fatal error: 'ffi.h' file not found
```
Relocation is a common scenario in macOS applications and frameworks.
This commit provides a mechanism to support relocations by inferring
the typelib dir from the path of the loaded image libgirepository-1.0.dylib.
glib-compile-schemas considers XDG_DATA_HOME in addition to
XDG_DATA_DIRS since GLib 2.53.2, but this is not mentioned in its manual
and might bring confusion to readers.
Commit d0e03f09 introduced GTYPE_TO_POINTER/GPOINTER_TO_TYPE, on which
work started before the move of conversion macros to Markdown. It did
get merged after that move, but the macros never made it into the docs.
Let's do so now.
Neither the new nftw()-based rm_rf() implementation, nor the fallback
implementation, should fail the test if there is an error during cleanup
of the directory tree. And the output on stderr that the nftw()-based
implementation emits should not interfere with Meson parsing the TAP
stream on stdout.
The test is run in a subprocess so that we can clean up after ourselves.
Previously, when cleaning up the temporary directory tree created by
passing G_TEST_OPTION_ISOLATE_DIRS, any symbolic links in that tree
would be followed recursively. If the test case has created a symbolic
link in its temporary directory to a directory outside that tree, this
could lead to unexpected data loss; in particular, if the test case
author has (unwisely) created a symbolic link to /, they could lose all
data on the system.
On systems that have the ftw.h header, replace the current rm_rf()
implementation with one that uses nftw() to perform a depth-first
traversal (FTW_DEPTH) without following symbolic links (FTW_PHYS), and
without crossing mount points (FTW_MOUNT) in case a test has mounted
some other filesystem in the temporary directory.
The callback logs any error to the standard error stream, but returns 0
rather than -1 to allow nftw() to keep walking the tree rather than
terminating immediately. Suppose we are trying to clean up the following
tree:
tmpdir/
a/
f/ (directory not readable for some reason)
g/
p
b/
c
d
Since tmpdir/a/f is not readable, we can expect to fail to delete
tmpdir/a/f, tmpdir/a and tmpdir; but it is preferable to (attempt) to
delete the rest of the tree rather than failing outright. The cost is
that three errors will be logged (for tmpdir/a/f, tmpdir/a and tmpdir).
nftw() is part of POSIX.1-2001, SUSv1, and glibc ≥ 2.1, so should be
available on effectively every platform except Windows. (And Windows
does not enable symbolic links by default so the developer error is less
likely to occur there.)
The macOS ftw(3) manpage says:
> These functions are provided for compatibility with legacy code. New
> code should use the fts(3) functions.
fts(3) does not seem to be part of any standard, but it does seem to be
equally widely supported. The Linux manpages do not indicate that
nftw() is deprecated.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3290
There is no need to use double backticks. Also, insert extra newlines
between header and item, which paragraphs the item [1, 2], increading
readability by giving a little more "breathing" room between items. This
is also done in `macros.md`. Also, indentation of the definition block
should technically be 4 if extra paragraphs are needed, but it's better
to use 4 indentation always to prevent future problems after edits.
[1] https://python-markdown.github.io/extensions/definition_lists/
[2] https://michelf.ca/projects/php-markdown/extra/#def-list
Do not try to inject the C standard into `c_args`: Meson already
generates a compiler command line with the appropriate C standard, and
adding another one into it at a random position is either potentially
undefined behaviour, or it's going to break the build because the
compiler does not accept more than one switch.
Meson has an `override_options` argument for the executable() object,
and we are already using it in places.
It’s not needed, and is now failing with:
```
meson.build:2578:36: ERROR: Feature systemtap cannot be enabled: Cannot enable systemtap because dtrace feature is disabled
A full log can be found at /builds/GNOME/glib/_build/meson-logs/meson-log.txt
```
See https://gitlab.gnome.org/GNOME/glib/-/jobs/3901860
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
