Since
https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/173,
there is now a really surprising implication to using a non-default
GTlsDatabase: your database could do nothing at all other than wrap the
default database, which you would expect to result in no behavior
changes, but in fact it causes fewer security checks to be performed
during certificate verification. This is because certificate
verification moved from GTlsDatabase to GTlsConnection, allowing for
more security checks to be performed. But if using a non-default
GTlsDatabase, we have to fall back to letting GTlsDatabase to the
verification, as before.
This is the best we can do. It's not a regression for applications,
because it means applications get the previous pre-2.72 behavior. But it
does mean that new security checks added in 2.72 are not applied, which
is unfortunate, so we should warn developers about this.
This feature has been reverted for now because I messed up the
implementation and it was doing sync I/O during async API calls. Oops!
Since it's not present in 2.70 nor in 2.72, let's remove the reference
to the exact GLib version that this behavior was introduced in. I'd like
to get it working properly for 2.74, but it's not ready yet and just
changing the version to 2.74 feels optimistic.
Rather than waiting for a fixed period of time, poll in a loop until the
condition the test is expecting is true.
A better solution would be to use a `GSource` and wait until that’s
dispatched. But doing so might affect the behaviour of the
`GInputStream` under test, so busy-wait instead.
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/1630758
```
(some socket debug output)
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1037:test_converter_pollable: assertion failed (res == -1): (1 == -1)
```
I could not reproduce the failure remotely with a few hundred
invocations of the test, so it might only present itself on BSD, which
presumably has different socket timing behaviour from Linux.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead of Windows 7/8/8.1 Server, use the proper names Server 2008
R2/2012/2012 R2 so that things are clearer to people. Since nowadays
GLib requires Windows 7 (_WIN32_WINNT 0x0601, meaning the server
counterpart is Server 2008 R2), we include Server 2008 in the list for
completeness' sake, but exclude the Server 2003/2003R2 from the list.
This improves how we obtain the Windows release versions in
get_windows_version(), in turn g_get_os_info() for Windows Server 2016
and later, and Windows 10 20H2 (2009) and later and Windows 11, by doing
the following:
* Check the build number. For Windows 11, the build number is 22000+;
for Windows Server 2022, the build number is 20348, and for Windows
Server 2019, the build number is 17763. We know what OS build
numbers to check for by the Windows OS type that we obtained by using
g_win32_check_windows_version(). Show the actual server release
string (i.e. Windows Server 20xx yyyy) as appropriate, as a result.
* Check the DisplayVersion entry in the registry under
SOFTWARE\Microsoft\Windows NT\CurrentVersion if we obtained "2009"
from the ReleaseId entry, since DisplayVersion replaces ReleaseId
after Windows 10/Server 2019 20H2 (2009). This makes things more
clear for Windows releases after 20H2, where previously 20H2
and 21H1 were all identified as Windows 10 [Server] 2009.
This should fix issue #2443.
Unfortunately, we may well be likely to need to call RtlGetVersion() via
GetModuleHandle() + GetProcAddress(), so split out the call to RtlGetVersion()
into a private function of its own, so that we can reuse the same code in other
parts of GLib, so that we can:
* Determine better in a more fine-tuned way to determine whether we are on
Windows 10/11 and/or Server 2016/2019/2022, since we need to rely on the
build number.
* Just call RtlGetVersion() once, when needed, as that is all that is needed.
We could re-use the same function once to compare what we got when we
called RtlGetVersion() and do what is necessary there.
Some function such as atk_text_get_text, use -1 to indicate the end of the
string. And an crash occurs when the -1 is passed to g_utf8_substring.
Call Trace:
0 __memmove_avx_unaligned_erms
1 memcpy
2 g_utf8_substring
3 impl_GetText
4 handle_other
5 handle_message
6 _dbus_object_tree_dispatch_and_unlock
7 dbus_connection_dispatch
8 dbus_connection_dispatch
9 ()
10 g_main_dispatch
11 g_main_context_dispatch
12 g_main_context_iterate
13 g_main_context_iteration
14 g_application_run
15 main
Signed-off-by: Chen Guanqiao <chen.chenchacha@foxmail.com>
There are no compiler warnings when building on macOS CI at the moment,
so let’s keep it that way by turning any future ones into errors.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously they were only passed to the C compiler, which meant disabled
warnings were still emitted when (for example) including C headers from
C++ and ObjC files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/tests/gio-du.c: In function 'main':
gio/tests/gio-du.c:74:11: error: parameter 'argc' set but not used
74 | main (int argc, char **argv)
| ~~~~^~~~
gio/ginputstream.c: In function 'g_input_stream_real_skip':
gio/ginputstream.c:433:31: error: comparison of integer expressions of different signedness: 'goffset' {aka 'long long int'} and 'long long unsigned int'
433 | (start + count) > (guint64) end)
| ^
glib/gutf8.c: In function 'g_utf8_get_char_extended':
glib/gutf8.c:626:39: error: comparison of integer expressions of different signedness: 'guint' {aka 'unsigned int'} and 'gssize' {aka 'int'}
626 | if (G_UNLIKELY (max_len >= 0 && len > max_len))
| ^
glib/gmacros.h:1091:27: note: in definition of macro 'G_UNLIKELY'
1091 | #define G_UNLIKELY(expr) (expr)
| ^~~~
glib/gutf8.c:628:21: error: comparison of integer expressions of different signedness: 'guint' {aka 'unsigned int'} and 'gssize' {aka 'int'}
628 | for (i = 1; i < max_len; i++)
| ^
gio/gwin32appinfo.c: In function 'uwp_package_cb':
gio/gwin32appinfo.c:3383:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_extgroups->len; i++)
^
gio/gwin32appinfo.c:3389:29: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_ext = 0; i_ext < grp->extensions->len; i_ext++)
^
gio/gwin32appinfo.c:3430:35: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_verb = 0; i_verb < grp->verbs->len; i_verb++)
^
gio/gwin32appinfo.c:3463:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < ext->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c:3478:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_protocols->len; i++)
^
gio/gwin32appinfo.c:3541:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < url->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c: In function 'g_win32_app_info_launch_internal':
gio/gwin32appinfo.c:4799:37: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (p_index = 0; p_index <= g_strv_length (envp); p_index++)
^~
gio/gwin32packageparser.c: In function 'WIN32_FROM_HRESULT':
gio/gwin32packageparser.c:99:30: warning: comparison of integer expressions of different signedness: 'long unsigned int' and 'long int'
if ((hresult & 0xFFFF0000) == MAKE_HRESULT (SEVERITY_ERROR, FACILITY_WIN32, 0) ||
^~
Rather than using the fixed-type compiler builtins
(`__builtin_uadd_overflow()`, etc.), use the generic versions
(`__builtin_add_overflow()`). This avoids issues with matching the
definition of GLib types (such as `guint` and particularly `gsize`) to
basic C types (`int`, `long`, `long long`), as the mapping can vary
between platforms.
See https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
Adjust the fallback inline functions similarly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2523
We now guarantee that GObjects will always be allocated at least as
aligned as the basic types. If you want to put an element in your
GObject which has higher alignment requirements, we can’t guarantee it
will be aligned*. If you need it to be aligned, you’ll need to put it on
the heap (aligned appropriately), or add appropriate padding in your
GObject struct.
*Actually, GSlice will guarantee that the whole GObject is aligned to at
least the power of 2 greater than or equal to the size of the GObject,
which means any element in the GObject struct should always be
appropriate aligned if the compiler pads it appropriately. If malloc()
is used, however, it doesn’t make that guarantee, so we can’t make that
guarantee overall.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1231
Regardless of the actual alignment of the GTypeInstance in question,
these do a runtime check on the type, so if the type was originally
aligned correctly when allocated, it should be aligned correctly if the
type check succeeds. -Wcast-align is meant to warn about casts between
types, which this isn’t (if the check succeeds).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1231
