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.
