The error code is already used for both F_DUPFD and dup2
already, and having dup2 in the name is oddly specific.
This renames the error code for clarity.
Now that we know it's a bad idea to avoid the standard io fd range
when getting pipe fds for g_unix_open_pipe, we should test to make sure
we don't inadvertently try to do it again.
This commit adds that test.
g_unix_open_pipe tries to avoid the standard io fd range
when getting pipe fds. This turns out to be a bad idea because
certain buggy programs rely on it using that range.
This reverts commit d9ba615090Closes: #2795Reopens: #16
The SPDX-License-Identifier said LGPL-2.1-or-later, but the license
grant was a permissive license, which we now identify as
LicenseRef-old-glib-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
This allows them to be referenced in other symbols value computation.
In addition, this fixes the automatically assigned value of a public
symbol that is preceded by a private one:
typedef enum {
/*< private >*/
ENUM_VALUE_PRIVATE,
/*< public >*/
ENUM_VALUE_PUBLIC, <--- value is 1, not 0.
} SomeExampleEnum;
This is a verbatim conversion of the GVariant Specification from
https://people.gnome.org/~desrt/gvariant-serialisation.pdf /
https://raw.githubusercontent.com/ostreedev/gvariant-rs/master/docs/gvariant-serialisation.pdf
to reStructuredText.
This is for several reasons:
1. The canonical copy has gone offline due to people.gnome.org being
shut down.
2. GLib is the reference implementation of GVariant, so should probably
host the specification (unless someone wants to host it on
freedesktop-specs).
3. Moving it out of a PDF and into reStructuredText should allow for
amendments. The specification has a few problems, typos and
oversights in its original form, and it would be good to canonically
fix them without having to write a separate addendum document.
This conversion is verbatim, and does not change the content of the
document at all, even to fix typos and broken links (which there are a
small number of in the PDF).
This describes what I’m labelling as version 1.0 of the GVariant
serialisation format. Updates to the specification can bump this version
number, in subsequent commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Similar to g_source_set_static_name, this avoids
strdup overhead for debug-only information in
possibly hot code paths.
We also add a macro wrapper for g_task_set_name that
uses __builtin_constant_p to decide whether to use
g_task_set_name or g_task_set_static_name.
We already set names on most sources, this
one was just forgotten. This lets us set
a static name, and prevents g_task_attach_source
from setting a non-static one.
The platform-specific predefined macros provided by various compilers
sometimes capture subtle differences of meaning, like the distinction
between the Linux kernel and a glibc-based (GNU/Linux) user-space.
It would be difficult to capture those subtleties in GLib-specific
convenience macros, particularly for platforms that we don't use
ourselves.
Instead, recommend that anyone who is already writing platform-specific
code should use the platform-specific predefined macros directly.
Alternative to !2986.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Enum symbols can be defined with a value computed from previously
defined enum symbols. The current evaluator does not support this and
requires a literal integer expression.
This commit introduces a C symbol namespace that is filled along
code generation and provided as a local namespace for new symbols
evaluation, effectively allowing definitions such as:
typedef enum {
a = 4;
b = a + 2;
} myenum;
to be successfully processed.
Setting installed_tests option enforces various test files to be
installed, this causes meson to build tools that might have not built
otherwise but that are still required for testing.
Also, disabling installed tests lead to slightly different code paths
when it comes to using test test files.
So, disable it for debian so that we can ensure that at test time we
have set all the dependencies between test programs and the used
resources (that can be libraries, external programs or modules).
Various glib tests (such as the spawn ones) depend on local binaries
being built, this may not happen (especially when not using installed
tests), thus ensure such dependencies via the newly added extra_programs
key
We need to make sure that such binaries are built and available at test time
or we may fail some tests requiring them (directly or through desktop file).
As per this, and because now generated desktop files are available both
at build and install time, don't skip some tests we were used to, but
actually enforce they are running.
We have some test programs on which some tests depend on, for example
appinfo-test is a tool that is used by the desktop-app-info tests.
So test can now have an 'extra_programs' key where the extra program
names can be included.
This could have been handled manually via 'depends', but this allows
to avoid repeating code and be sure that all is defined when extra
programs targets are checked.
`g_app_info_launch_default_for_uri_async()` has already returned by this
point, so waiting a long time is not really going to help.
Wait for 3× as long as the successful case took, which should allow for
long enough to catch true negatives, with a bit of variance.
On my system, this means waiting for about 14ms, rather than the 100ms
which this previous slept for. This speeds the test up by about 5%.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We were generating .desktop files with different content when installed
tests were enabled, and thus making impossible to test some cases
because there was no built file until installed.
To avoid this, always generate both versions of desktop files while
install only the one containing the install path prefix if needed.
