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>
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.
