We were previously relying on it returning `EINVAL` so we could return
an error message, but scan-build doesn’t like that, so let’s just
explicitly return the same error anyway to shut scan-build up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The value of `errno` can apparently be undefined after a successful
function call (according to scan-build), so only check `errno` on
failure.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than reporting an error via a new `GTask`, report it via the
`GTask` we’ve already created. This avoids a critical warning about
destroying the `GTask` without returning a result.
Also ensure to disconnect the D-Bus signal subscription first, to avoid
an assertion failure in `call_data_free()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3798
As per commit 0144feb41 the activate action paramter may pack multiple
values but while the behavior was checked we did not check the content
of the values we were receiving in the action callback.
So, also ensure that the variant values we receive are matching the
expectations.
Instead of guessing the portal file name by using the original file name
let's just inspect the portal document ID directory and get the actual
file name
In order to properly test the document portal, let's also create some
dummy files that are named after the FDs we receive and using the
document-id path as the real portal does
When an URI to a symlink is added to the portal, we open it and we send
the FD (of the target) to the portal. This one has no clue about the original
symlink and so it mounts a file that is named like the target.
g_document_portal_add_documents(), however returns a path that contains
the original name and that one is what is sent to the applications when
used via GDesktopAppInfo.
Basically, this is the situation:
- /tmp/symlink -> /tmp/target
- An application is launched to open file:/tmp/symlink
- The portal creates file:/$XDG_RUNTIME_DIR/doc/ID/target
- Gio converts the path to file:/$XDG_RUNTIME_DIR/doc/ID/symlink
Now, since we can't just pass the symlink to the portal without also
changing the logic there, it's just better to do the conversion ourself,
and so, we use the already-opened fd to figure out the real path of the
opened file, and we return a document file URI that uses the target
basename instead
It routinely fails with subproject fetch errors, typically at least
every second CI run. This wastes a lot of CI machine time, and a little
bit of developer time and energy each time (in noticing that it’s
failed, context switching, checking the failure, retrying it, context
switching again).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: https://gitlab.gnome.org/GNOME/glib/-/issues/3715
- Redid the old StarOffice-format drawing file in OpenDocument
format, and updated with two different `-light` and `-dark`
versions.
- Added color to the rectangles
- Bolded all of the text
- Added background transparency
- Exported both as `file-name-encodings-{light,dark}.svg`
- Tweaked in Inkscape to simplify SVG structure, scale to
fixed pixel sizes, align to page dimensions.
- Added License/Copyright data as Custom Document Properties
in OpenDocument sources, comments in SVG source.
- Federico Mena Quintero, uploader of the originals, is
credited in the `SPDX-FileCopyrightText` data, along
with myself.
- License chosen was `CC0-1.0`, because again I don't believe
these files are complex enough to actually be copyrightable.
- Added data for `.odg` files to `/.reuse/dep5` file, as
reuse can't extract license data from that format.
- Updated `character-set.md` and `glib.toml.in` to use
new SVGs in place of old PNG.
The RFC9110 explanation of HTTP ETags is far superior to
the disjoint ramblings found in (now-obsoleted) RFC2616,
and serves as a much better reference for comparison
with GFile entiity tags. Also, link directly to relevant section.
Also might exist on FreeBSD or other systems which support /proc, so this codepath will run on these systems but won't fail since it checks if the file exists anyway
The maximum values can expand to something containing `__extension__` on
some platforms (like msys2-clang64), and the preprocessor can’t
understand that.
So, use the type widths rather than their maximum values instead. This
is equivalent, but definitely won’t expand to `__extension__`.
Should hopefully fix the following compiler error on msys2-clang64:
```
../glib/tests/strfuncs.c:667:5: error: function-like macro '__extension__' is not defined
667 | #if G_MAXSIZE > G_MAXUINT
| ^
glib/glibconfig.h:89:19: note: expanded from macro 'G_MAXSIZE'
89 | #define G_MAXSIZE G_MAXUINT64
| ^
../glib/gtypes.h:107:21: note: expanded from macro 'G_MAXUINT64'
107 | #define G_MAXUINT64 G_GUINT64_CONSTANT(0xffffffffffffffff)
| ^
glib/glibconfig.h:70:34: note: expanded from macro 'G_GUINT64_CONSTANT'
70 | #define G_GUINT64_CONSTANT(val) (G_GNUC_EXTENSION (val##ULL))
| ^
../glib/gmacros.h:62:26: note: expanded from macro 'G_GNUC_EXTENSION'
62 | #define G_GNUC_EXTENSION __extension__
| ^
1 error generated.
```
(as seen in https://gitlab.gnome.org/GNOME/glib/-/jobs/5608465)
Co-authored by: Luca Bacci <luca.bacci982@gmail.com>
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Regression from 501ff95c. Union member offsets are always 0, but we need
to mark them as 'COMPUTED' otherwise they are not written to the
typelib, which results in gi_field_info_get_offset() returning 0xffff.
Since gi_field_info_get/set_field() cannot check that the offset is
within the size of the struct or union, that means poking into invalid
memory addresses.
This also adds some basic tests for GIFieldInfo which would have caught
this bug.
Closes: #3745
Compiling with clang 21.1.2 leads to following warning:
```
../glib/tests/cxx.cpp:566:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
566 | }
```
Add the theoretically missing return statement, even though the if-block
should always be reached. Since no other compiler warned about the
unreachable statement with this change, this should be okay.
