This is detected by Debian's Lintian tool, which suggests
"allows one to" as a replacement. I've rephrased the documentation
in question to avoid both of those.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
The text about deallocation of GArrays with elements containing
dynamically-allocated memory was confusing. It initially mentioned
clear_func, but later said elements with dynamically allocated memory
"should be freed separately".
Clarify this by using the same structure as g_ptr_array_free —
highlight the need to set a clear_func by consolidating the text about
it in a separate paragraph.
https://gitlab.gnome.org/GNOME/glib/merge_requests/348
None of these files starts with a #! line, and they are not native
binary executables, so if a user attempts to execute them as a program,
Unix shells will run them as /bin/sh scripts. This is not going to end
well, since none of them are shell scripts (the gio bash completion
is for bash, which is not a lowest-common-denominator POSIX shell, and
in any case is designed to be sourced rather than executed).
Fixes: #1539
Signed-off-by: Simon McVittie <smcv@collabora.com>
As we recently established, G_G*_FORMAT macros are for glib
functions *only*. It's not guaranteed that they will work for
C runtime printf() or scanf() variants, and indeed - in this case
they do not (GCC thinks that MSVCRT sscanf() requires %I64 prefix
for 64-bit values; whether that is true or not is irrelevant at this
point - we need to make the werror go away).
LPARAM is LONG_PTR which is the same as INT_PTR on Windows.
WPARAM is UINT_PTR.
HWND is a pointer.
(%p prints pointers without 0x prefix, hence the extra 0x).
These keep on taking just longer than 30s on my local machine when run
in parallel with the rest of the tests (i.e. with `ninja test`). Testing
them individually, they do terminate correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, in the case where 'kf' has more than one ref, calling
g_key_file_free(kf) would break it. For example, calling
g_key_file_has_key(kf, ...) would hit the following assertion:
g_hash_table_lookup: assertion 'hash_table != NULL' failed
This is because g_key_file_free() calls g_key_file_clear() which sets
self->groups and other fields to NULL; most lookup functions assume
these fields are non-NULL.
One fix would be to call g_key_file_init() right after
g_key_file_clear() in g_key_file_free(). However, in the case where
there are no other refs to the keyfile, this would mean allocating
many new hash tables which will be immediately destroyed when
g_key_file_unref() removes the last ref. Instead, inline the unref, and
re-initialize the internal state when the keyfile is still alive.
1) Creating a directory with 0666 does not prevent
traversal on Windows (ACL determines the possibility
of traversal, and Windows mkdir() does not translate
permission bits into ACL). Don't do the traversal check on Windows.
2) Creating a file with 0555 also isn't translated into
read-only ACL, Windows sets the read-only attribute instead,
which blocks all changes, including changes to file times.
Add the write permissions on Windows before changing file times.
It turns out that UCRT (which is the C runtime that Visual Studio
uses by default these days) quietly changed the semantics for
stat() functions and its variants. Previously they provided data
for the symlink (if the file queried was a symlink), now they
provide data for the target of the symlink.
glib used to call _wstat64() to get certain stat-ish data about
files, such as st_dev, since it was deemed that computing that
data in glib using custom code would be pointless, as _wstat64()
worked just fine.
With UCRT this is no longer true. This commit drops _wstat64() in
favour of a bunch of custom calls that populate the stat buffer
manually. This way glib correctly gets information about a symlink,
not its target.
The _fstat64() call is still being used, as it does not suffer
from this problem and thus remains untouched.
Even if we're using a prime modulo for the initial probe, our table is
power-of-two-sized, meaning we can set the mask simply by subtracting one
from the size.
Sequential integers would be densely packed in the table, leaving the
high-index buckets unused and causing abnormally long probes for many
operations. This was especially noticeable with failed lookups and
when "aging" the table by repeatedly inserting and removing integers
from a narrow range using g_direct_hash() as the hashing function.
The solution is to multiply the hash by a small prime before applying
the modulo. The compiler optimizes this to a few left shifts and adds, so
the constant overhead is small, and the entries will be spread out,
yielding a lower average probe count.
g_icon_new_for_string() docs states that it should return a single name
when created with a single name. I add a second condition to this case:
the themed icon must not include default fallbacks (i.e. it must not
have been created with `g_themed_icon_new_with_default_fallbacks()`).
Otherwise the return value of `g_icon_new_for_string()` would not
recreate the same icon list when passed to `g_icon_new_for_string()`
(which would be another documentation inconsistency).
g_icon_new_for_string() is now back to old behavior for this specific
case.
I also revert the unit test for this case, and add a new unit test when
using g_themed_icon_new_with_default_fallbacks() with a single name as
well.
Closes#1513.
