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.
This is what’s available in the new Debian Stable, so we can expect it
to be available pretty much everywhere.
Subsequent commits will clean up old workarounds.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The package naming is confusing. It turns out we’ve been installing the
wrong libpcre version for ages, but haven’t noticed because the correct
version has previously been installed on the system by default.
It seems that Debian Bullseye doesn’t have the old libpcre installed by
default, so now we have to fix this package name and make sure it’s
installed in the CI images. Building it as a subproject is a pain.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously, the code validated that child objects have a path with the
object manager strictly as a prefix. That doesn’t work in the case where
the object manager’s path is `/`. This case is not recommended, but is
supported.
If the object manager’s path is `/`, validate that child objects’ paths
are not equal to it. If they are equal to it, warn the user rather than
emitting a critical warning, since we can’t expect any users who’ve not
been compliant with the spec to instantly rework their D-Bus APIs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2500
0.2 was just tagged, which includes a commit from 2018 that fixes a
meson warning which caused the project to fail to build on Windows with
--fatal-meson-warnings enabled.
