While gtk-doc can currently detect a link to a symbol which has been
pluralised by adding ‘s’, it can’t detect when ‘es’ is added. While
that’s being fixed, reword the documentation so the links are generated
correctly anyway.
gtk-doc fix here: https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/22
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.
In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If using the --interface-info-{body,header} options to gdbus-codegen,
and the first interface to be outputted has no methods, but does have
properties or signals, an uninitialised variable would be used for the
property/signal ‘since’ values.
In other situations, the ‘since’ value for a prior method would have
been incorrectly used for the properties/signals.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The test performs implicit autolaunching of a bus
and checks if it is connectible.
In build the test is moved from "only non-windows with have_dbus_daemon"
to "anywhere".
This is intentional: actually it doesn't execute any external
binaries on unix (so doesn't require dbus_daemon)
and now has win32 implementation.
The test has some problems that are not problems of test itself,
but are reasoned by current win32 implementation:
- since the implementation uses global win32 kernel objects
with fixed names not depending on g_get_user_runtime_dir or other context
if preexisting bus running by some other libgio-using application
the test would silently pass.
- since the implementation uses problematic time-based synchronization,
that has a race condition between opening and reading mmaped address,
the test may randomly fail (I'd not seen this in practice).
- since the implementation autolaunched process works for 3 seconds
after last client disconnects, the executed subprocess runs for 3 seconds
after test exit, maybe locking the libgio-2.0-0.dll file for that time.
This is a bit of breaking change:
After this commit the apps relying of win32 dbus autolaunching,
need to install gdbus.exe alongside with libgio-2.0-0.dll.
A new command for gdbus tool is used for running server:
gdbus.exe _win32_run_session_bus
To implement it gdbus.exe uses the same exported function
g_win32_run_session_bus that earlier was used by rundll.
So (private) ABI was not changed.
It runs the bus syncronously, exiting after inactivity timeout -
all exactly like it was runed earlier with the help of rundll32.
While private exported function may have _some_
version compatibility issues between gdbus.exe and libgio-2.0-0.dll
compiling dbus server registration logic directly into gdbus.exe
can lead to _more hidden and more complex_ compatibility issues
since the names and behaviour of syncronization objects
used to publish server address would be required compatible between
gdbus.exe and libgio-2.0-0.dll.
So using "private" exported function to call
looks like more safe behaviour.
gdbus.exe binary was selected for this task since
it has corresponding name and at least for msys2 is shippied
in same package with libgio-2.0-0.dll
turn_off_the_starting_cursor function is also kept as is,
however it is not obvious if it is still needed
(by now I failed reproducing original issue).
Explicit g_warnings added to help with possible
problematic cases for absent or incompatible gdbus.exe
Mainloop is created after successful daemon creation
Before this change the function leaked mainloop on daemon creation fail
nm_conn_to_g_conn already handles UNKNOWN like NONE (returning
G_NETWORK_CONNECTIVITY_LOCAL in both cases). So in sync_properties
we should also set new_connectivity to G_NETWORK_CONNECTIVITY_LOCAL
for both NM_CONNECTIVITY_UNKNOWN and NM_CONNECTIVITY_NONE.
This has the added benefit that when NetworkManager returns the network
connectivity is UNKNOWN, we set network_available to FALSE as it should
be. Previously, there were cases in a laptop with no network access,
that g_network_monitor_get_network_available returned true, which was
wrong and is also fixed with this commit.
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to allow GLib itself to be built with G_DISABLE_ASSERT defined,
we need to explicitly undefine it when building the tests, otherwise
g_test_init() turns into an abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1708
g_assert_*() give more informative error messages on failure, and can’t
be disabled by G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows referencig them from more than single .c file.
Implementation moved without changes
from gdbusaddress.c to gdbusprivate.c
g_win32_run_session_bus signature also kept, so ABI unchanged.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1566
Short names were used in win32 implementation to allow launching
on installations where full path to libgio-2.0-0.dll contain spaces.
However, short names are optional on windows: so if they were disabled
that method fails - see issue linked above.
Since rundll32 doesn't support neither spaces, nor quotes in cmdline
this patch changes rundll32 argument to just .\gio-dll-name.dll
and uses the entire path directory containing gio dll as rundll32
current directory.
Added comments informing about potential subtleties discovered during
writing test for gdbusaddress on win32.
There are not known to have real-world user-visible effect,
so by now I'm only adding comments without creating issues.
Commit f975858e86 removed the NULL check in g_cancellable_cancel() by
accident which makes it crash when called with NULL.
Add the check back and add a test so this doesn't happen again.
Fixes#1710
Implement the approach suggested in
https://gitlab.gnome.org/GNOME/glib/merge_requests/276
1. Try to open O_RDWR. On success, pass that fd
2. If EACCESS => fail the trash op, we "need" read-write to successfully trash it
3. If EISDIR => re-open the fd with O_PATH, and pass that (which will fail on snap,
but verify the dir for flatpaks)
Don’t pollute the build directory with files generated by running the
test.
Note that there are still other tests in the gsettings.c test suite
which use the build directory, but fixing them is a bit more involved
than I have time for right now. This is a step in the right direction.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
res_ninit() requires the __res_state struct passed to it to be
zero-filled on FreeBSD.
Spotted and analysed by Ashish SHUKLA.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes#1697
Synchronize access to cancelled flag of cancellable, which was
previously access without synchronization in g_cancellable_is_cancelled.
Use atomic operations instead of existing global mutex, to avoid
serializing calls to g_cancellable_is_cancelled across all threads.
Ensure that source is attached to the context before it migth be used
from another thread, since otherwise operation on source are
unsynchronized and not thread-safe.
In particular there was a data race between g_source_attach and
g_source_set_ready_time (used from g_file_monitor_source_handle_event).
This essentially reverts commit
cffed58737.
The preceding two commits have fixed the test so it’s no longer flaky.
The following command gives 5000 passes in a row for me:
meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1679
It’s occasionally possible for the cancellation of the service to happen
before connection_cb() gets scheduled in the other thread. The
locking/unlocking order of mutex_712570 requires:
• test_threaded_712570(): lock mutex
• test_threaded_712570(): start wait loop
• connection_cb(): lock mutex
• test_threaded_socket_service_finalize(): unlock mutex
• test_threaded_712570(): end wait loop
• test_threaded_712570(): unlock mutex
Fix that by quitting the main loop once connection_cb() has been called
(i.e. once the server thread has received the incoming connection
request), rather than just after the client thread (main thread) has
sent a connection request.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
On about 1 in 3 test runs, the socket-service would fail with the
ref_count assertion in connection_cb() failing (the ref_count would be 3
rather than the expected 2).
This was happening because the GTask from
g_socket_listener_accept_socket_async() now always takes at least one
main context iteration to return a result (whereas before
6f3d57d2ee it might have taken zero), but
the ref_count can drop below 3 before the process of returning a result
starts. During the process of returning a result, the ref_count
temporarily increases again, which is what was breaking the test.
Fix this by waiting for one more main context iteration. This is a bit
of a hack, but the real fix would be to expose the outstanding_accept
boolean from GSocketService as public API (which the test can
interrogate), and that seems too much like exposing internal state.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
Almost everything that needs gioenumtypes.h also needs
gobjectenumtypes.h. Fixes:
ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
In file included from ../gio/win32/gwin32filemonitor.h:25:0,
from ../gio/win32/gwin32filemonitor.c:26:
../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
#include <gobject/gobjectenumtypes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIO modules built with MSVC do not begin with 'lib', but they can
begin with 'gio'. Without this, you can only load GIO modules built
with MSVC that are `name.dll`, not `gioname.dll`.
Eliminate several cases of splitting sentences between multiple
translatable strings, and remove some newlines from the translatable
strings (they always need to be present, and can confuse translation, so
add them unconditionally afterwards).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Compilers get confused when variables are initialized by a function by
taking them as reference in an out argument; this, coupled with the fact
that C does not initialize variables by default, most commonly results
in a "maybe uninitialized" compiler warning.
512e9b3b34 added a call to schedule_pending_close() in the read
callback after the reference to the worker is already gone. In case this was
the last reference to the worker this resulted in a use-after-free.
6f3d57d2ee made this more likely to happen because on connection close
the worker cancel action is now async while the reference to the worker
gets dropped right away.
Move the call to schedule_pending_close() before the unref.
Fixes#1686
When testing as root, changing the permissions of the keyfile will have
no effect on the writability since root bypasses these permissions. See
path_resolution(7). Skip the test in this case.
g_assert_*() give more informative error messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
getsockname() returns the address that the socket was bound to.
If it was bound to INADDR_ANY, getsockname() will stubbornly return INADDR_ANY
(and someport - that one is valid).
Subsequent connection attempts to INADDR_ANY:someport will fail with winsock.
Actually, it doesn't make even sense to connect to INADDR_ANY at all
(where is the socket connecting to? To a random interface of the host?),
so this is just a straight-up change, without platform-specific ifdefing.
Use loopback instead of INADDR_ANY. To ensure that binding and creation
of INADDR_ANY is still tested, use two addresses: bind to INADDR_ANY,
but connect to loopback, with the port number that we got from the bound
address.
Use a static GQueue to form the GList of mounts by appending (which
is fast, because GQueue tracks the tail pointer of its internal GList),
then return that GList. This way we don't need to form the list
by prepending, which would have made it necessary to reverse it before
returning.
If the list is not ordered correctly, local drives in GTK places sidebar
are shown in reverse order.
The gsocketclient-slow test needs this, otherwise connect() succeeds
immeidately and the test fails, because it is checking that cancellation
works. We weren't installing it for installed tests.
It's necessary sometimes for installed tests to be able to run with a
custom environment. For example, the gsocketclient-slow test requires an
LD_PRELOADed library to provide a slow connect() (this is to be added in
a followup commit).
Introduce a variable `@env@` into the installed test template, which we
can override as necessary when generating `.test` files, to run tests
prefixed with `/usr/bin/env <LIST OF VARIABLES>`.
As the only test that requires this currently lives in `gio/tests/`, we
are only hooking this up for that directory right now. If other tests in
future require this treatment, then the support can be extended at that
point.
There's no /tmp directory on Windows.
Use g_get_tmp_dir(), and adjust the test to work with that.
The test *still* checks the basename of the new CWD, it just
doesn't need to be "tmp" anymore.
envp in spawn() functions is the *whole* environment table
for the child process. Including PATH. Thus, unless PATH is explicitly
put into that table, the process will be spawned without PATH.
Since on Windows binaries are found via PATH instead of LD_LIBRARY_PATH
or whatever, almost no program (unless installed in WINDIR, maybe)
can run without a PATH. Certainly not test programs - meson
adds bld subdirs to the PATH to make sure that test programs
use uninstalled glib at runtime.
So make sure that PATH is passed along.
Windows \r\n EOLs strike again. The test already knows about LINEEND,
so make it use LINEEND more (instead of swithcing pipes
to binary mode). This also applies to counting the bytes
read.
With winsock sending messages to NULL results in G_IO_ERROR_NOT_CONNECTED
instead of G_IO_ERROR_FAILED.
MSDN says:
WSAENOTCONN
10057
Socket is not connected.
A request to send or receive data was disallowed because the socket is not connected
and (when sending on a datagram socket using sendto) no address was supplied.
So this is a direct mapping of the implementation error.
Covering it up in the wrapper (by converting it to G_IO_ERROR_FAILED)
doesn't seem feasible or needed (no one, except for the testsuite,
really cares which unrecoverable error is returned by sendto()).
getaddrinfo() in winsock can't understand scope IDs.
There's no obvious way to fix that, short of re-implementing
that function, so disable that part of the test on Windows.
G_RESOURCE_OVERLAYS is a list of resource-path and filesystem-path pairs.
Since on Windows filesystem paths use ':', this list can't be ':'-separated
there. Fix that by making it ';'-separated on Windows. Make the parser
error clearer (we're not looking for a slash, we're looking for an absolute
path).
If a URI can't be handled by by WinHTTPVfs, it should pass that URI
along to the URI parser of the wrapped Vfs, not to its generic parser.
Theoretically, generic parser should also be able to handle URIs,
but this is subject to Vfs semantics.
In case of Windows, the wrapped Vfs is GLocalVfs, which is *local* and
treats any generic names as either file:// URIs or as filesystem
paths. It only ever treats URIs as URIs when they are passed
to its URI parser. This breaks the testsuite when g-icon GIO test passes
unhandleable sftp:// URI, and expects it to come through unmolested,
yet GLocalVfs, getting that URI as a generic parse name, treats it as
a filesystem path, and then "canonicalizes" it by prepending CWD.
Fix this by making WinHTTPVfs pass any URIs it gets to the URI parser
of the wrapped Vfs. This way unknown URIs remain URI-ish. This seems
like a reasonable things to do, since the URI parser should not be
given anything other than URIs, so there's no reason to try generic
parsing with these strings.
Closes: #875
Previously once the end of addresses was reached it would return
NULL even if it was waiting on a dns response. Now it will keep
waiting so all addresses are received.
Fixes#1680
Currently, the actual asynchronous work, represented by
asynchronous_cancellation_run_task, was over before the GCancellable
could be triggered. While that doesn't invalidate the purpose of the
test, since it's fundamentally about cancellation, it would be
nicer if the cancellation actually served some purpose instead of
being a mere formality.
https://gitlab.gnome.org/GNOME/glib/issues/1608
When calling g_socket_listener_accept_socket_async() on a
GSocketListener with multiple sockets, the accept_ready() callback is
called for the first incoming connection on each socket. It will return
success/failure for the entire accept_socket_async() GTask, and then
free the GSources for listening for incoming connections on the other
sockets in the GSocketListener. The GSources are freed when the GTask is
finalised.
However, if incoming connections arrive for multiple sockets within the
same GMainContext iteration, accept_ready() will be called multiple
times, and will call g_task_return_*() multiple times, before the GTask
is finalised. Calling g_task_return_*() multiple times is not allowed.
Propagate the first success/failure, as before, but then ignore all
subsequent incoming connections until the GTask is finalised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Once cancelled, a GTask's callback should not only be invoked
asynchronously with respect to the creation of the task, but also with
respect to the GCancellable::cancelled handler. This is particularly
relevant in cases where the cancellation happened in the same thread
where the task is running.
Spotted by Dan Winship and Michael Catanzaro.
Closes https://gitlab.gnome.org/GNOME/glib/issues/1608
It needs investigating and fixing properly, but let’s not let it disrupt
the CI in the meantime.
Follow-up in https://gitlab.gnome.org/GNOME/glib/issues/1679.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
To make things consistent across the board as that is the WinSock2 error
code that is received by g_socket_send_message_with_timeout() when it
returns G_POLLABLE_RETURN_WOULD_BLOCK.
This never caused any problems because the default GSettingsBackend is
cached forever by GIOModule anyway.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
I was trying to debug some memory leaks in the gsettings test.
Eventually, it seems that actually they’re caused by the
GMemorySettingsBackend being cached by GIOModule — so this commit makes
no functional changes. It should make the code and documentation a bit
clearer though.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This mostly affects the 2.56 branch, but, given that GCC 9 is being
stricter about passing null string pointers to printf-like functions, it
might make sense to proactively fix such calls.
gdbusauth.c: In function '_g_dbus_auth_run_server':
gdbusauth.c:1302:11: error: '%s' directive argument is null
[-Werror=format-overflow=]
1302 | debug_print ("SERVER: WaitingForBegin, read '%s'",
line);
|
gdbusmessage.c: In function ‘g_dbus_message_to_blob’:
gdbusmessage.c:2730:30: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
2730 | tupled_signature_str = g_strdup_printf ("(%s)", signature_str);
|
The recent changes of the g_app_info_launch_default_for_uri_async()
function ensures that the callback is not called before DBus-activated
applications start. Let's use g_app_info_launch_default_for_uri_async()
and remove the workarounds for DBus-activated applications.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1249
The g_app_info_launch_uris_async() and g_app_info_launch_uris_finish()
functions are crucial to fix g_app_info_launch_default_for_uri_async()
to be really asynchronous.
This patch also adds GDesktopAppInfo implementation of that vfuncs.
The implementation may still use some synchronous calls to local MIME DB.
https://gitlab.gnome.org/GNOME/glib/issues/1347https://gitlab.gnome.org/GNOME/glib/issues/1249
In the writev() tests, the handling of cancellation is tested. However,
the GCancellable was cancelled after the writev_async() call was
started. Depending on the implementation of the writev() vfunc, the
operation could be done in a thread or in callbacks on the current
thread’s main loop. If done in a separate thread, there’s a chance that
enough of the write could happen before cancellation reaches that thread
that the overall operation returns success with a short write.
That would cause the test to fail, sometimes.
Avoid that by cancelling the GCancellable before starting the writev()
operation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
It would always be initialized but initialize it to NULL to silence the
compiler, and also check that it is not NULL anymore when we expect it
to contain a valid value.
../gio/tests/desktop-app-info.c: In function ‘test_fallback’:
../gio/tests/desktop-app-info.c:191:18: warning: ‘app’ may be used uninitialized in this function [-Wmaybe-uninitialized]
g_assert_true (g_app_info_equal (info1, app));
^~~~~~~~~~~~~~~~
It could've never been uninitialized in this code but the code flow is
not obvious to the compiler. Initialize it to NULL and for clarity also
add an assertion that it is not NULL anymore on usage.
In file included from ../glib/glib.h:62,
from ../gobject/gbinding.h:28,
from ../glib/glib-object.h:23,
from ../gio/gioenums.h:28,
from ../gio/giotypes.h:28,
from ../gio/giomodule.h:28,
from ../gio/giomodule.c:25:
../gio/giomodule.c: In function ‘_g_io_module_get_default’:
../glib/gmessages.h:343:25: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define g_debug(...) g_log (G_LOG_DOMAIN, \
^~~~~
../gio/giomodule.c:912:17: note: ‘extension’ was declared here
GIOExtension *extension, *preferred;
^~~~~~~~~
This allows returning WOULD_BLOCK without allocating a GError, and
should later be used for various functions of GPollableOutputStream,
GPollableInputStream and anything else that can potentially block.
Interpret the value "help" for environment variables that
are passed to _g_io_module_get_default(), and print the
names and priorities of available extensions.
This lets users explore what is available, and can be helpful
in figuring out why a certain extension was chosen as default.
It is similar in spirit to what we already do with environment
variables like G_DEBUG.
This is useful for debugging in many situations. It’ll be printed with
G_MESSAGES_DEBUG=GLib-GIO or G_MESSAGES_DEBUG=all.
Mostly I need it for debugging the default GNetworkMonitor, but it will
work for all GIO module implementations.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When we are in a sandboxed situation, bump the priority
of the keyfile settings backend above the dconf one,
so we use a keyfile inside the sandbox instead of requiring
holes in the sandbox for dconf.
Stacked databases and locks are dconf features that allow
management software like Fleet Commander to set system-wide
defaults and overrides centrally for applications.
This patch adds minimal support for the same to the keyfile
backend. We look for a keyfile named 'defaults' and a
lock-list named 'locks'.
Suitable files can be produced from a dconf database with
dconf dump and dconf list-locks, respectively.
The default location for these files is /etc/glib-2.0/settings/.
For test purposes, this can be overwritten with the
GSETTINGS_DEFAULTS_DIR environment variable.
Writes always go to the per-user keyfile.
Make it possible to instantiate a keyfile settings backend
without specifying parameters, by turning the arguments to
the new() function into construct-only properties. If no
filename is specified, default to
$XDG_CONFIG_HOME/glib-2.0/settings/keyfile
It needs investigating and fixing properly, but let’s not let it disrupt
the CI in the meantime.
Follow-up in https://gitlab.gnome.org/GNOME/glib/issues/1653.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There's a race here, as revealed by Debian's buildds.
We call g_dbus_proxy_new() to create a proxy for the test server, with
callback proxy_ready() Then we call g_spawn_command_line_async() to
start the test server, and then start the main loop.
proxy_ready() assumes that the test server hasn't been started when it
is called. But there is no guarantee that these asynchronous operations
involving spawning a process won't happen in a different order that mean
the bus name *does* have an owner.
What we can do is move starting the server inside of proxy_ready(), so
we know that the test server isn't started until after the proxy is
created. We also add an assertion to check that it is indeed not running
before we execute it.
Rather than storing it as an invalid value in last_position, store it as
a separate boolean.
This introduces no functional changes, but should fix some warnings from
MSVC.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1500
If we can't find the mount point for target or tmp (as currently
happens on Launchpad autobuilders, and perhaps relatedly, on a
development system that uses btrfs), that's probably not great but is
not really the point of this test.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a minimal autobuilder environment, this test could conceivably be
the first thing to refer to ~/.local.
Modified by Iain Lane <laney@debian.org>: Don't try to create ~/.local
from tests, but skip if it doesn't exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Like for the OpenURI portal, O_PATH file descriptors do not prove access
to the underlying file data. I've used O_RDWR file descriptors here to
mirror the requested read/write permissions.
This change relates to https://github.com/flatpak/xdg-desktop-portal/issues/167
The OpenURI portal requires the caller to pass a file descriptor as
proof of access for local files. Old versions required this file
descriptor to use the O_PATH mode. However, this does not prove access
since you can create O_PATH descriptors for files that you can't read.
Since xdg-desktop-portal 1.0.1, regular file descriptors are also
accepted with O_PATH descriptors restricted to flatpaks for the
transition.
Check for over- and underflow when manipulating positions.
This makes the sequence
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
return NULL for the second call, as it should.
Closes: #1639
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
Since commit 290bb0dd, where various members of GTask were converted to
a bitfield, some of the getters:
• g_task_get_check_cancellable()
• g_task_get_return_on_cancel()
• g_task_get_completed()
have been returning truthy ints (zero or an arbitrary non-zero integer)
as boolean values, rather than the canonical boolean ints of 1 and 0.
This broke the `yield` statement in Vala, whose generated C code
compares `g_task_get_completed (…) != TRUE`. i.e. Whether the
`completed` field has a value not equal to 1.
Fix this by explicitly converting truthy ints to canonical boolean ints
in all getters.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1636
Names are a message bus feature, so it does not make sense to connect
to NameOwnerChanged when the underlying connection is not a message
bus.
Moreover, g_dbus_connection_signal_subscribe() will also enforce that
condition. Adding this extra check here is helpful to avoid a critical
warning when using GDBusProxy with peer-to-peer connections.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Right now this can only be set at construction but not read back.
That seems unnecessarily restrictive, and we'll need to read these
flags from outside of gdbusconnection.c in the next commit, so let's
just make it public.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Add option to not encode resource data into the C source file
in order to embed the data using `ld -b binary`. This improves compilation
times, but can only be done on Linux or other platforms with a
supporting linker.
(Rebased by Philip Withnall, fixing minor rebase conflicts.)
Fixes#1489
This reverts commit 52bab0254a.
It silently conflicted with another commit,
90ca3b4dd0, which was merged later than
it. I’ve kept commit 90ca3b because it also frees the GError; 52bab
doesn’t.
This is my failure to rebase and test old branches before merging them,
instead of assuming that the lack of automatically detected merge
conflicts actually means there are no merge conflicts.
Allow any type of private key in PEM files by treating PEM guards ending
with "PRIVATE KEY-----" as a private key instead of looking for a
pre-defined set of PEM guards. This enables the possibility for custom
GTlsBackend to add support for new key types.
Test cases have been expanded to ensure PEM parsing works for private
key when either header or footer is missing.
Encrypted PKCS#8 is still rejected. Test case has been added for this to
ensure behaviour is the same before and after this change.
The `apps` subprocess is spawned by desktop-app-info to interpret the
forest of .desktop files, and its output is provided on stdout. If debug
output is mixed up with that output, tests which parse the output fail.
Disable the debug output from the subprocess to prevent this.
The new debug output appeared as a result of recent changes to the
desktop file dir monitoring code in gdesktopappinfo.c.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
