See the previous commit. Clarify these variable names so it’s more
obvious they contain a size in bytes rather than a length in wide-chars.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3649
It can be confusing otherwise when getting string values: is the size in
bytes or wide-characters?
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3649
`value_size` is in bytes, whereas `ms_resource_prefix_len` is in wide
characters, so they cannot be compared directly. This meant that if
12 ≤ `value_size` < 24 then the call to `memcmp()` would read off the
end of `value`.
Fix it by using a wide-character and nul-aware comparison function and
operating only on wide-lengths. This is safe because
`g_win32_registry_key_get_value_w()` guarantees that string-typed return
values are nul-terminated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3649
This can happen if a user passes a ludicrously long string to argv.
Spotted by chamalsl as #YWH-PGM9867-48.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The AI_ADDRCONFIG flag filters out addresses for invalid interfaces. This causes it to resolve nothing when only having loopback interfaces.
So we can detect if you only have loopback interfaces, request all addresses, and filter out non-loopback results.
Closes#3641
This ensures they’re not writing files to the build directory, which
avoids race conditions when running multiple invocations of the tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not currently needed, because the filename being passed to the
subprocess is hard-coded and doesn’t contain anything which would need
escaping. But the following commit is going to change that (to avoid
filename collisions), so let’s fix the quoting first.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This ensures they’re not writing files to the build directory, which
avoids race conditions when running multiple invocations of the tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
So the filename we delete at the end of the test is definitely the same
one we created at the start of the test.
This introduces no functional changes, but will make a refactor in the
following commit simpler.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This ensures they’re not writing files to the build directory, which
avoids race conditions when running multiple invocations of the tests.
This is not entirely trivial, because the tests for
`g_key_file_load_from_data_dirs()` are affected by the overridden
`$XDG_DATA_HOME` directory. Mitigate that by copying the file they want
to that directory (and relying on `G_TEST_OPTION_ISOLATE_DIRS` to delete
it again afterwards).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Today I learned that it magically turns `-` into `/` to search
subdirectories for key files. Turns out that wasn’t documented at all.
i.e. it’ll search for `$datadir/some-key-file.ini` and, if that’s not
found, will then try `$datadir/some/key-file.ini` and then
`$datadir/some/key/file.ini`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than creating files in the current directory. This is a bit
neater, and avoids races between parallel invocations of the unit tests
if the file names aren’t guaranteed to be unique (e.g. by using
`g_mkstemp()`).
Add `G_TEST_OPTION_ISOLATE_DIRS` too, to make sure we use a unique
subdirectory of `g_get_tmp_dir()`. This means that paths like
`g_get_tmp_dir() / some-file` are guaranteed to be race-free even if the
filename is not unique, because the test tmp dir now is.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In the `g-file-info-filesystem-readonly` test.
This doesn’t introduce any functional changes, but makes the code a
little easier to read (because the parts of the path are now in
hierarchical order) and makes it a bit clearer that we’re building a
path rather than an arbitrary string.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Otherwise it’s easy to assume that they create a file in the system
temporary directory, if they’re only called with a filename template
(without a path).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not entirely clear from the documentation, but `g_mkstemp()` (and
`g_mkdtemp()`) operate in the current directory, rather than the system
temporary directory.
This meant these tests were all writing files to the build directory.
This is messy, though thankfully not a correctness issue or a race
because `g_mkstemp()` guarantees to return a unique file for each
caller.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This probably wasn’t causing any problems since it was a self-contained
read only access of a non-existent path. But it’s a bit tidier to
contain this all inside `/tmp`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Like many things I touch, I broke this in
fd8ede0b661aa67032bbc3e7afc88aff22d7984a.
Spotted by Sebastian Wilhelmi in
fd8ede0b66 (note_2385263).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Previously, we were getting the string representation. However, this
representation gets escaped, which breaks non-ascii characters, because we
were counting on the path being the original path, which was not true in
these cases.
Retrieve it rather as the byte string which it is.
Fixes#3636.
Previously, we would call
g_datalist_id_set_data (&object->qdata, quark_closure_array, NULL);
which called destroy_closure_array() on the CArray.
At that point, it would iterate over the CArray, and invalidate all
closures. But note that this invokes external callbacks, which in turn
can destroy other closures, which can call object_remove_closure().
But now that closure can no longer be found and an assertion fails.
Instead of removing the entire CArray at once, remove each closure one
by one in a loop.
This problem is similar to issue 1002, except here it's about closure
watches instead of GWeakNotify.
Note that now we destroy closures one-by-one in a loop, and we iterate
the loop as long as we have closures. That makes a difference when a new
closure gets registered while we destroy them all. Previously, newly
registered closures would survive. It would be possible to implement the
previous behavior, but I think the new behavior is better. It is anyway
a very remote use case.
Its symbol interposition works differently to that of Linux, so our
approach using `dlsym(RTLD_NEXT)` to inject syscalls (and still allow
chaining up to the version from libc) doesn’t work on macOS.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/4861349 for an example
failure.
It would be lovely to have these tests working on macOS, but I am not a
macOS developer, and have spent enough time fixing this leak (#1250)
already. It can wait for follow-up work.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1250
The algorithm that `g_socket_listener_add_any_inet_port()` and
`g_socket_listener_add_inet_port()` use to try to connect to IPv4 and/or
IPv6 ports are a bit complex (especially when port allocation has to
happen in the former method). So far they’ve not really been unit
tested, which is unfortunate, and has left latent bugs.
Add some unit tests for both methods, by providing mock `socket()` (and
friends) functions to override those from libc, and using those to cause
specific syscalls to fail according to the test’s needs.
These tests demonstrate the fix for #1250 works, as the tests can be run
under memcheck and show no memory leaks. They’ve revealed a follow-up
issue, though — `g_socket_listener_add_any_inet_port()` doesn’t try a
fallback IPv4-only socket if it tries an IPv6 socket and that socket
accepts IPv4 but then fails to `listen()`. I’ve filed issue #3604 for
that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1250
