With a trivial file that just includes glib.h:
#include <glib.h>
Compiled with:
gcc -c test.c \
-I /tmp/glib/include/glib-2.0/ \
-I /tmp/glib/lib/x86_64-linux-gnu/glib-2.0/include \
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_28 \
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_28 \
-fmax-errors=1 \
-Werror
We get:
In file included from /tmp/glib/include/glib-2.0/glib/gasyncqueue.h:32,
from /tmp/glib/include/glib-2.0/glib.h:32,
from test.c:1:
/tmp/glib/include/glib-2.0/glib/gthread.h: In function ‘g_rec_mutex_locker_new’:
/tmp/glib/include/glib-2.0/glib/gthread.h:396:3: error: ‘g_rec_mutex_lock’ is deprecated: Not available before 2.32 [-Werror=deprecated-declarations]
396 | g_rec_mutex_lock (rec_mutex);
| ^~~~~~~~~~~~~~~~
/tmp/glib/include/glib-2.0/glib/gthread.h:196:17: note: declared here
196 | void g_rec_mutex_lock (GRecMutex *rec_mutex);
| ^~~~~~~~~~~~~~~~
compilation terminated due to -fmax-errors=1.
The problem is that the code in the static inline functions uses
g_rec_mutex_lock, introduced after 2.28. This code is compiled
regardless of if it's actually used or not.
Suppress the warning by using G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS. There are precedents for doing that,
for example g_main_context_pusher_new in gmain.h.
Tested by building with all variations of GLIB_VERSION_MIN_REQUIRED /
GLIB_VERSION_MAX_ALLOWED:
for i in $(seq 26 2 64); do
gcc -c test.c \
-I/tmp/glib/include/glib-2.0 \
-I/tmp/glib/lib/x86_64-linux-gnu/glib-2.0/include \
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_$i \
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_$i \
-fmax-errors=1 \
-Werror
done
Fixes: #2094
pip in MSYS2 seems to install scripts into $USERPROFILE instead of $HOME
which means the MSYS2 meson, which is newer, wins. Make sure $USERPROFILE
is in PATH as well.
g_ptr_array_extend_and_steal() leaves the GPtrArray in an invalid state,
so if you would try to append another pointer, it leads to a crash.
Also adjust the test case so that it would result in the crash (without
the fix).
Fixes: 0675703af08d ('Adding g_ptr_array_extend_and_steal() function to glib/garray.c')
There’s no need to call `access()` and then `stat()` on the keyring
directory to check that it exists, is a directory, and has the right
permissions. Just call `stat()`.
This eliminates one potential TOCTTOU race in this code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1954
There was a time-of-check-to-time-of-use (TOCTTOU) race in the keyring
lock code, where it would check the existence of the lock file using
`access()`, then proceed to call `open(O_CREAT | O_EXCL)` to try and
create the lock file once `access()` showed that it didn’t exist.
The problem is that, because this is happening in a shared directory
(`~/.dbus-keyrings`), another process could quite legitimately create
the lock file in the meantime.
Instead, unconditionally call `open()` and ignore errors from it (which
will be returned if the lock file already exists) until it succeeds (or
the code times out).
This eliminates the TOCTTOU race, and simplifies the timeout behaviour
so there aren’t two loops (check for existence, try to create)
happening. It brings this code in line with what dbus.git does (see
`_dbus_keyring_lock()`).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1954
When multiple tests were run in parallel, this would race on its access
to `~/.dbus-keyrings` to authenticate with the D-Bus server, since the
keyring directory was not appropriately sandboxed to the unit test.
Use `G_TEST_OPTION_ISOLATE_DIRS` to automatically isolate each unit
test’s directory usage.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1954
gitlab will drop cmd.exe support with GitLab 13 so I took the opportunity to
add new runners with Windows 2016 and powershell as default.
These runners are tagged with win32-ps instead of win32. The old runners
will be switched off in the coming weeks.
The main difference is that all commands and env expansions use powershell
and Windows 2016 instead of 2012r2.
The GIO tests memory-monitor-dbus and memory-monitor-portal use a number
of third party Python modules that may not be present when running the
test case.
Instead of failing due to missing imports, catch the ImportError and
mock a test case that skips. This can't use the usual unittest.skip
logic because the test case class itself uses a 3rd party module.
Closes#2083.
There are two memory monitor tests that use Python's unittest module directly,
but GLib tests should be outputting TAP. Use the embedded TAPTestRunner to
ensure that TAP is output for these tests too.
By default, meson builds glib with -Werror=format=2, which
implies -Werror=format-nonliteral. With these flags, clang errors
out on e.g. the g_message_win32_error function, due to "format
string is not a string literal". This function takes a format
string, and passes the va_list of the arguments onwards to
g_strdup_vprintf, which is annotated with printf attributes.
When passing a string+va_list to another function, GCC doesn't warn
with -Wformat-nonliteral. Clang however does warn, unless the
functions themselves (g_message_win32_error and set_error) are decorated
with similar printf attributes (to force the same checks upon the
caller) - see
https://clang.llvm.org/docs/AttributeReference.html#format
for reference.
Adding these attributes revealed one existing mismatched format string
(fixed in the preceding commit).
The G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE attribute doesn't have to be
always set. See https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/68
for more details. In that case, the g_file_query_default_handler function
fails with the "No application is registered as handling this file" error.
Let's fallback to the "standard::fast-content-type" attribute instead to
fix issues when opening such files.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1425
New features were added for gio tool, but they are not mentioned in
man pages as it is not generated from GOptionEntry in contrast to the
help output. Let's update the man pages to reflect the recent changes.
Skip the gdbus-object-manager-example which is generated as part of
testing.
Program xsltproc found: YES (/usr/bin/xsltproc)
Run-time dependency gtk-doc found: YES 1.32
docs/reference/gio/gdbus-object-manager-example/meson.build:1:0: ERROR:
Unknown variable "libgdbus_example_objectmanager_dep".
malloc() was given too small value (size of pointer,
rather than struct it points to), and subsequent call
getpwnam_r() wrote past the end of allocated block - easily
seen with valgrind.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Don't assume that __MINGW32__ implies x86; Windows runs on ARM/ARM64
as well, and there are mingw toolchains that target those architectures.
This mirrors how the MSVC part of the same expressions are written,
as (defined(_WIN32) && defined(_M_IX86)) and
(defined(_WIN64) && defined(_M_X64)) - not relying on _WIN32/_WIN64
or __MINGW32__/__MINGW64__ alone to indicate architecture.
The __declspec(dllexport) attribute in itself doesn't imply
'extern' - thus any intended variable declaration with
GLIB_VAR/GOBJECT_VAR would actually be a variable definition. With
C compilers defaulting to -fcommon, this isn't an issue, but
upcoming compilers (GCC 10 and Clang 11) will default to -fno-common,
ending up with duplicate definitions of these variables.
It was checking for the main SOCKS5 version number, rather than the
subnegotiation version number. The username/password authentication
protocol is described in https://tools.ietf.org/html/rfc1929.
Spotted and diagnosed by lovetox.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1986
If a username and password are specified by the caller, `GSocks5Proxy`
tells the server that it supports anonymous *and* username/password
authentication, and the server can choose which it prefers.
Otherwise, `GSocks5Proxy` only says that it supports anonymous
authentication. If that’s not acceptable to the server, the code was
previously returning `G_IO_ERROR_PROXY_AUTH_FAILED`. That error code
doesn’t indicate to the caller that authentication might succeed were
they to provide a username and password.
Change the error handling to make that clearer. A fuller solution would
be to expose more of the method negotiation in the `GSocks5Proxy` API,
so that the caller can specify ahead of time which authentication
methods they want to use. That can follow in issue #2059 though.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1988
Distributions will likely want to update GLib before
GObject-Introspection, to avoid circular dependencies.
Signed-off-by: Simon McVittie <smcv@debian.org>
Guard against NULL type being passed to
g_content_type_get_generic_icon_name() just as we protect
g_content_type_get_description(), otherwise it will cause a crash.
See https://gitlab.gnome.org/GNOME/gtk/issues/2482
