...and add ability to select target platform for calling vcvarsall.bat,
so that we can accomodate 32-bit builds and possibly ARM64 builds in the
CI if we need to.
This patch fixes a build error when compiling with GCC cross compiler for Windows on ARM64.
See issue #3490 for details.
Signed-off-by: Carlo Bramini carlo_bramini@users.sourceforge.netFixes: #3490Closes#3490
This arm of the condition is always true, because 0x00 has been checked
in the previous branch.
This is not going to improve performance, but does mean we now have full
branch coverage of the code via our unit tests, which gives some
assurance that it’s all good.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3481
The move to c-utf8 for validation has exposed a few new branches where
our existing (fairly comprehensive) UTF-8 validation test suite didn’t
check things.
Add unit tests for those branches, so we keep code coverage.
I’ve validated (with an independent UTF-8 decoder) that the test vectors
are correctly marked as valid/invalid in the test data (so the tests
aren’t just blindly coded to match the behaviour of the new validator
code).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3481
It turns out it’s not actually been explicitly tested before, even
though it has full code coverage through being called by other code
which is tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Scanning for stop chars can require looking through a considerable amount
of input data. In the case there is a single stop character, use memchr()
which can be optimized by the compiler to look at word size or greater
amounts of data at a time.
This moves g_str_is_ascii() from gstrfuncs.c to gutf8.c so that we can
reuse the same SIMD code for ASCII validation.
On Apple Silicon:
Before: 3297 MB/s
After: 26146 MB/s
This is based on the https://github.com/c-util/c-utf8 project and has
been adapted for portability and integration into GLib. c-utf8 is dual
licensed Apache-2.0 and LGPLv2.1+, the latter matching GLib.
Notably, `case 0x01 ... 0x7F:` style switch/case labels have been
converted to if/else which is more portable to non-GCC/Clang platforms
while generating the same assembly, at least on x86_64 with GCC.
Additionally, `__attribute__((aligned(n)))` is used in favor of
`__builtin_assume_aligned(n)` because it is more portable to MSVC's
`__declspec(align(n))` and also generates the same assembly as GCC's
`__builtin_assume_aligned(n)`.
For GCC x86_64 Linux on a Xeon 4214 this improved the throughput of
g_utf8_validate() for ASCII from 750MB/s to around 10,000MB/s (13x).
On GCC aarch64 Linux with an Apple Silicon M2 Pro we go from about
2,200 MB/s to 26,700 MB/s (12x).
Closes: #3481
Instead of using singleton initialized the first time when it's needed
we can create the `DBusProxy` object when needed without blocking since
the interface doesn't have any properties nor signals.
The docs recommend using a small number of `keys` when setting data for an
object, the OpenURI portal uses three different `keys` that can easily be replaced
with `g_task_set_task_data()`.
We can’t quite use `access()` for this, like `g_file_test()` does, as
`g_file_query_info()` considers a broken symlink to exist, so we need to
match that by passing `AT_SYMLINK_NOFOLLOW`.
We also use the `AT_EACCESS` flag, which makes the `faccessat()` call
cheaper on Hurd.
Systems without `faccessat()` will continue to use the
`g_file_query_info()`-based implementation of `g_file_query_exists()`.
(Commit message rewritten by Philip Withnall.)
g_file_query_exists looks like a simpler and faster api than
g_file_query_info. This vfunc lets us actually make it faster,
and avoid allocations in this frequently used code path.
It wasn’t previously clear (to me) whether `end` was returned pointing
to the nul terminator, or to the byte immediately preceding it. Try and
clarify that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For the reasons given in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4176#note_2233317,
it’s best to not rely on subprocesses when writing tests. Spawning a
subprocess can go wrong, getting feedback and assertion data from a
subprocess is a pain, and making sure the subprocess is killed properly
at the end of the test is hard to get right.
For tests where we are trying to mock a D-Bus service, it’s much more
reliable to run that service in-process (either in the main thread or in
a separate thread).
So, do that for the `fake-document-portal` former subprocess in the
`dbus-appinfo` test: move it to a worker thread.
This speeds the test up, simplifies the build slightly, and should make
the test run more reliable.
In particular, it provides a pattern for future `fake-*-portal` tests to
be built off. This is particularly useful for more complex portals,
where data needs to be relayed back from the mock portal service to the
unit test to check that the code under test has behaved properly. That’s
a pain to do from a subprocess.
Delete the `org.freedesktop.portal.Documents.service` file because we no
longer need to rely on D-Bus service activation within the test, as
we’re setting up the mock service thread explicitly now.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Nobody’s going to keep it up to date if it’s floating about in an
unrelated place, not next to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Nobody’s going to keep it up to date if it’s floating about in an
unrelated place, not next to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Just like we have `g_steal_pointer()` and `g_clear_pointer()`, it would
be useful to have a ‘steal’ version of `g_clear_handle_id()`.
Particularly in situations where a clear function can’t be represented
as a `GClearHandleFunc`, such as
`g_dbus_connection_signal_unsubscribe()` (there’s no way of passing the
`GDBusConnection` to it) — or in situations where a handle ID isn’t
being released, but is being passed from one struct to another or from a
local scope to a struct or vice-versa.
Includes unit tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
And to not assume that every main context iteration will provide
progress on the sources that the test is interested in. It’s possible
that other sources may be attached to the `GMainContext` which get
dispatched instead of the pipe sources on an iteration.
I don’t know if this will fix#3483, but it will certainly make this
test a little tidier. It doesn’t affect test run time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3483
Otherwise `scan-build` thinks it’s possible for the `GBytes` to be
double-freed, which would indeed happen if `try_steal_and_unref()` were
to return `NULL` on this branch.
It’s not actually possible for it to return `NULL` here though, as if
`bytes->data` were `NULL`, the function would have already returned
higher up.
Fixes this `scan-build` failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/4359929
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This fixes commit 9eb9df2396, which I really should have noticed at the
time would cause a load of unused variables to be declared if compiled
with `G_DISABLE_ASSERT`. That’s what the original `#ifdef`s were to
protect against.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
