glib/gwin32.c: In function 'g_win32_check_windows_version':
glib/gwin32.c:556:32: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'gint' {aka 'const int'}
if (osverinfo.dwMajorVersion > major)
^
glib/gwin32.c:558:37: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'gint' {aka 'const int'}
else if (osverinfo.dwMajorVersion == major)
^~
glib/gwin32.c:560:36: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'gint' {aka 'const int'}
if (osverinfo.dwMinorVersion > minor)
^
glib/gwin32.c:562:41: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'gint' {aka 'const int'}
else if (osverinfo.dwMinorVersion == minor)
^~
glib/gtimezone.c: In function 'rules_from_windows_time_zone':
glib/gtimezone.c:926:56: warning: comparison of integer expressions of different signedness: 'int' and 'DWORD' {aka 'long unsigned int'}
for (year = first, i = 0; *rules != NULL && year <= last; year++)
^~
glib/gtimezone.c:946:20: warning: comparison of integer expressions of different signedness: 'int' and 'DWORD' {aka 'long unsigned int'}
if (year > first && memcmp (®tzi_prev, ®tzi, sizeof regtzi) == 0)
^
glib/gtimezone.c: In function 'set_tz_name':
glib/gtimezone.c:1481:25: error: comparison of integer expressions of different signedness: 'int' and 'guint' {aka 'unsigned int'}
1481 | len = *pos - name_pos > size - 1 ? size - 1 : *pos - name_pos;
| ^
glib/gtimezone.c:1481:49: error: operand of '?:' changes signedness from 'int' to 'guint' {aka 'unsigned int'} due to unsignedness of other operand
1481 | len = *pos - name_pos > size - 1 ? size - 1 : *pos - name_pos;
| ^~~~~~~~~~~~~~~
glib/gtimezone.c: In function 'rules_from_identifier':
glib/gtimezone.c:1553:25: warning: comparison of integer expressions of different signedness: 'int' and 'guint' {aka 'unsigned int'}
for (i = 0; i < rules_num - 1; i++)
^
glib/gthread-win32.c: In function 'g_system_thread_new':
glib/gthread-win32.c:507:37: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ResumeThread (thread->handle) == -1)
^~
glib/gstdio.c: In function '_g_win32_stat_utf8':
glib/gstdio.c:763:45: warning: comparison of integer expressions of different signedness: 'gsize' {aka 'long long unsigned int'} and 'long long int'
(g_path_is_absolute (filename) && len <= g_path_skip_root (filename) - filename))
^~
glib/gstdio.c: In function 'g_win32_readlink_utf8':
glib/gstdio.c:896:15: warning: comparison of integer expressions of different signedness: 'glong' {aka 'long int'} and 'gsize' {aka 'long long unsigned int'}
if (tmp_len > buf_size)
^
glib/gpoll.c: In function 'poll_rest':
../glib/gpoll.c:165:22: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'unsigned int'
if (timeout_ms == INFINITE)
^~
glib/gpoll.c:219:18: warning: comparison of unsigned expression >= 0 is always true
else if (ready >= WAIT_OBJECT_0 && ready < WAIT_OBJECT_0 + nhandles)
^~
glib/gpoll.c: In function 'poll_single_thread':
glib/gpoll.c:281:44: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'unsigned int'
if (retval == 0 && (data->timeout_ms == INFINITE || data->timeout_ms > 0))
^~
glib/gpoll.c: In function 'g_poll':
glib/gpoll.c:477:52: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
retval = retval == -1 ? -1 : thread_retval == -1 ? -1 : retval + thread_retval;
^~
glib/gpoll.c:477:60: warning: operand of ?: changes signedness from 'int' to 'long unsigned int' due to unsignedness of other operand
retval = retval == -1 ? -1 : thread_retval == -1 ? -1 : retval + thread_retval;
^~
glib/gpoll.c:477:33: warning: operand of ?: changes signedness from 'int' to 'long unsigned int' due to unsignedness of other operand
retval = retval == -1 ? -1 : thread_retval == -1 ? -1 : retval + thread_retval;
^~
The "recursive:" kwarg is available in the targeted minimum version of
meson, and is basically required if you want to not emit warnings and
maybe error with --fatal-meson-warnings.
There are two basic solutions to this problem:
- The current default behavior is false, so explicitly opt in to that
value. None of these internal libraries use recursive objects anyway.
- Use link_with to link to the static library directly, rather than the
extracted objects.
Option 2 is what used to be done before commit
62af03bda8, but it only works with meson
>=0.52 and previously had buggy behavior.
Since the minimum version of meson is now 0.52, it is safe to revert
that commit and go back to using link_with, and therefore option 2 is
chosen.
glib/win_iconv.c: In function 'iso2022jp_mbtowc':
glib/win_iconv.c:1818:18: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (cv->mode != ISO2022_MODE(cs, shift))
^~
glib/win_iconv.c: In function 'iso2022jp_wctomb':
glib/win_iconv.c:1889:18: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (cv->mode == ISO2022_MODE(cs, shift))
^~
glib/gfileutils.c: In function 'g_file_test':
glib/gfileutils.c:375:18: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int'
if (attributes == INVALID_FILE_ATTRIBUTES)
^~
glib/gfileutils.c: In function 'g_get_current_dir':
glib/gfileutils.c:2882:40: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (GetCurrentDirectoryW (len, wdir) == len - 1)
^~
glib/gdate.c: In function 'win32_strftime_helper':
glib/gdate.c:2582:12: warning: comparison of integer expressions of different signedness: 'gsize' {aka 'long long unsigned int'} and 'glong' {aka 'long int'}
if (slen <= convlen)
^~
Despite their type, the values returned will always be ≥ 0. It’s
unfortunate they weren’t declared with an unsigned type, but we can’t
change that now without breaking API.
Spotted in !2294.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
glib/gspawn-win32.c: In function 'read_helper_report':
glib/gspawn-win32.c:329:16: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'long long unsigned int'
while (bytes < sizeof(gintptr)*2)
^
glib/gspawn-win32.c:366:13: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'long long unsigned int'
if (bytes < sizeof(gintptr)*2)
^
MSVC supports AddressSanitizer as well via "/fsanitize=address" option,
but __lsan_ignore_object() equivalent feature is not supported.
Note that there's __declspec(no_sanitize_address) specifier which
provides a similar feature but that's not runtime behavior
so it's not directly applicable to g_ignore_leak() family.
See also https://docs.microsoft.com/en-us/cpp/sanitizers/asan-building?view=msvc-160
glib/gslice.c: In function 'slice_config_init':
glib/gslice.c:394:16: warning: comparison of integer expressions of different signedness: 'int' and 'long long unsigned int'
else if (len >= G_N_ELEMENTS (wvalue))
^~
glib/genviron.c: In function 'g_getenv':
glib/genviron.c:490:52: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (GetEnvironmentVariableW (wname, wvalue, len) != len - 1)
^~
glib/genviron.c:507:60: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (tem, wvalue, len) != len)
^~
glib/gcharset.c:380:35: warning: comparison of integer expressions of different signedness: 'long long int' and 'long long unsigned int'
else if (modifier - dot < sizeof (buf))
^
This comment was added in a919be3d in 2013. The function basically looked the same
as now at that point. g_main_context_find_source_by_id() can clearly return NULL if
the source id is invalid, so unclear where this comes from? The function in
question are approximately the same since e2fd4e2b in 2000.
However back then g_main_context_find_source_by_id() would actually always return
the last source if there was none with the given source id (wat, that's clearly
unintended?). This was changed in 393503ba in 2014, arguably an API change of that
function but more arguably a bugfix :)
So for a short time between 2013 and 2014, that comment was correct. Now it is not
anymore and can be removed.
g_get_user_database_entry() capitalises the first letter of pw_name
with g_ascii_toupper (pw->pw_name[0]).
However, the manpage for getpwnam() and getpwuid() says the result of
those calls "may point to a static area". GLib is then trying to edit
static memory which belongs to a shared library, so segfaults.
The reentrant variants of the above calls are supposed to fill the user
buffer supplied to them, however Michael Catanzaro also found a bug in
systemd where the data is not copied to the user buffer and still points
to static memory, resulting in the same sort of segfault. See:
https://github.com/systemd/systemd/issues/20679
Solve both these cases in GLib by copying pw_name off to a temporary
variable, set uppercase on that variable, and use the variable to join
into the desired string. Free the variable after it is no longer needed.
Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
Previously, priority was not randomly generated and was instead derived
from `GSequenceNode*` pointer value.
As a result, when a `GSequence` was freed and another was created, the
nodes were returned to memory allocator in such order that allocating
them again caused various performance problems in treap.
To my understanding, the problem develops like this :
1) Initially, memory allocator makes some nodes
2) For each node, priority is derived from pointer alone.
Due to the hash function, initially the priorities are reasonably
randomly distributed.
3) `GSequence` moves inserted nodes around to satisfy treap property.
The priority for node must be >= than priorities of its children
4) When `GSequence` is freed, it frees nodes in a new order.
It finds root node and then recursively frees left/right children.
Due to (3), hashes of freed nodes become partially ordered.
Note that this doesn't depend on choice of hash function.
5) Memory allocator will typically add freed chunks to free list.
This means that it will reallocate nodes in same or inverse order.
6) This results in order of hashes being more and more non-random.
7) This order happens to be increasingly anti-optimal.
That is, `GSequence` needs more `node_rotate` to maintain treap.
This also causes the tree to become more and more unbalanced.
The problem becomes worse with each iteration.
The solution is to use additional noise to maintain reasonable
randomness. This prevents "poisoning" the memory allocator.
On top of that, this patch somehow decreases average tree's height,
which is good because it speeds up various operations. I can't quite
explain why the height decreases with new code, probably the properties
of old hash function didn't quite match the needs of treap?
My averaged results for tree height with different sequence lengths:
Items | before| after |
--------+-------+---------------+
2 | 2,69 | 2,67 -00,74% |
4 | 3,71 | 3,80 +02,43% |
8 | 5,30 | 5,34 +00,75% |
16 | 7,45 | 7,22 -03,09% |
32 | 10,05 | 9,38 -06,67% |
64 | 12,97 | 11,72 -09,64% |
128 | 16,01 | 14,20 -11,31% |
256 | 19,11 | 16,77 -12,24% |
512 | 22,03 | 19,39 -11,98% |
1024 | 25,29 | 22,03 -12,89% |
2048 | 28,43 | 24,82 -12,70% |
4096 | 31,11 | 27,52 -11,54% |
8192 | 34,31 | 30,30 -11,69% |
16384 | 37,40 | 32,81 -12,27% |
32768 | 40,40 | 35,84 -11,29% |
65536 | 43,00 | 38,24 -11,07% |
131072 | 45,50 | 40,83 -10,26% |
262144 | 48,40 | 43,00 -11,16% |
524288 | 52,40 | 46,80 -10,69% |
The memory cost of the patch is zero on 64-bit, because the new field
uses the alignment hole between two other fields.
Note: priorities can sometimes have collisions. This is fine, because
treap allows equal priorities, but these will gradually decrease
performance. The hash function that was used previously has just one
collision on 0xbfff7fff in 32-bit space, but such pointer will not
occur because `g_slice_alloc()` always aligns to sizeof(void*).
However, in 64-bit space the old hash function had collisions anyway,
because it only uses lower 32 bits of pointer.
Closes#2468
