It’s not clear why `ABS()` was ever needed here so, as per the previous
commit, let’s eliminate it.
It was added in d9f5ab56c3 owing to the need for a pseudo-random value
in the range (0, 1000000). Previously the code calculated a hash
(unsigned pseudo-random value in the full range of `unsigned int`), then
cast it to `int` (making half its possible values negative), then took
`ABS()` of that (forcing the negative values positive, so effectively
halving the pseudo-random state space and doubling the possibility of
any particular value being chosen), then did mod 1000000 to limit the
upper bound.
We can simplify this by eliminating the cast to `int`, which removes the
need for `ABS()`. The whole `unsigned int` state space is then passed to
mod 1000000. This should give the same probability distribution as
before.
The `timer_perturb` variable itself is signed to allow for `-1` to
indicate it’s not been set yet (it’s `static`). This could be split out
into a separate boolean, but there’s no point as the desired
`timer_perturb` state space is only (0, 1000000) anyway, which is easily
representable as a signed `int`.
Spotted by Thomas Haller in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4559#note_2384322.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s possible that `ABS()` will evaluate its argument more than once, so
it’s best to not call expensive functions as the argument expression.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Numeric macros such as MIN(), MAX(), etc. should not be handed
arguments with side-effects, such as i++, since we can't guarantee
that the values are only evaluated once.
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>
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.
As of gobject-introspection 1.83.2, a new `<doc:format name="…"/>`
element is supported (as a child of `<repository>`) in GIR files.
For the moment, this information isn’t needed in libgirepository — but
the GIR parser does have to know about the element in order to not throw
an error claiming it’s invalid.
This is a slightly tweaked version of the code added to
gobject-introspection.git in commit
9544cd6c962fab2c3203898779948309833e2439 by Corentin Noël
<corentin.noel@collabora.com>, reformatted slightly to fit in with
GLib’s style guidelines.
This is backwards compatible and does not require a new
gobject-introspection version.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3634
