Prevent the situation where errno is set by function A, then function B
is called (which is typically _(), but could be anything else) and it
overwrites errno, then errno is checked by the caller.
errno is a horrific API, and we need to be careful to save its value as
soon as a function call (which might set it) returns. i.e. Follow the
pattern:
int errsv, ret;
ret = some_call_which_might_set_errno ();
errsv = errno;
if (ret < 0)
puts (strerror (errsv));
This patch implements that pattern throughout GLib. There might be a few
places in the test code which still use errno directly. They should be
ported as necessary. It doesn’t modify all the call sites like this:
if (some_call_which_might_set_errno () && errno == ESOMETHING)
since the refactoring involved is probably more harmful than beneficial
there. It does, however, refactor other call sites regardless of whether
they were originally buggy.
https://bugzilla.gnome.org/show_bug.cgi?id=785577
The /etc/mtab file is still used by some distributions (e.g. Slackware),
so it has to be monitored instead of /proc/self/mountinfo in order to
avoid races between g_unix_mounts_get and "mounts-changed" signal. The
util-linux is built with --enable-libmount-support-mtab in that case and
mnt_has_regular_mtab is used for checks. Let's use mnt_has_regular_mtab
also to determine which file to monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=779607
Unlike g_application_register, there is no public API to unregister the
GApplication from D-Bus. Therefore, if the GApplication is set up
manually without using g_application_run, then neither can the
GApplicationImpl be destroyed nor can dbus_unregister be called before
destruction.
This is fine as long as no sub-class has implemented dbus_unregister.
If they have, their method method will be called after destruction, and
they should be prepared to deal with the consequences.
As long as there is no public API for unregistering, let's demote the
assertion to a WARNING. Bravehearts who don't use g_application_run
can continue to implement dbus_unregister, but they would have been
adequately notified.
This reverts commit c1ae1170fa.
https://bugzilla.gnome.org/show_bug.cgi?id=725950
Invoking the dbus_unregister virtual method during destruction is
problematic. It would happen after a sub-class has dropped its
references to its instance objects, and it is surprising to be asked to
unexport exported D-Bus objects after that.
This problem was masked as a side-effect of commit 21b1c390a3.
Let's ensure that it doesn't regress by asserting that dbus_unregister
has happened before destruction.
Based on a patch by Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=725950
When using the Freedesktop backend for GNotification, it seems like a
better idea to map G_NOTIFICATION_PRIORITY_HIGH to NOTIFY_URGENCY_NORMAL
(instead of NOTIFY_URGENCY_CRITICAL) provided that the difference
between GNotification's NORMAL and HIGH priorities is minor.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=784815
When building glib as a subproject, #include's for xdp-dbus.h from xdp-dbus.c
and for gdbus-daemon-generated.h from gdbus-daemon-generated.c were generated as
being prefixed with the subproject prefix, eg
#include "subproject/glib/gio/gdbus-daemon-generated.h".
That failed since the root of the build directory is obviously not part of the
include path when building a subproject.
Passing --output-directory @OUTDIR@ to gdbus-codegen and removing @OUTDIR@ from
--generate-c-code fixes the issue.
meson.source_root() returns the toplevel source directory
of the toplevel project, thus the paths were wrong when using
it. Simply using files() gets us the right path
https://bugzilla.gnome.org/show_bug.cgi?id=784133
With meson from git dependencies of dependencies are no
longer added automatically and recursively to the linker
lines. Meaning dependencies that are used have to be
passed directly and explicitly or we'll get linker errors.
Need to fix up some of the tests a little, because the
test binary will not necessarily be run from the current
build sub-directory, and the build directory structure
might not always be a mirror of the source directory
structure, so pass location of glib-mkenums and
glib-compile-scheme and such directly.
This reduces the build-time dependencies of glib to only Python 3,
Meson, and git. Git is also optional if you provide a tarball in
which the subproject directories already exist.
The Python port was done by Jussi Pakkanen on bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This version contains some fixes from that and also changes all
instances of `@` to `\u0040` because Meson does not yet provide a
configure_file() mode that ignores unknown @MACRO@ values.
This is a stub-only library that can be used while building against
MSVC and contains no i18n machinery at all.
The dependencies added indirectly use the libintl.h header, and when
built as a subproject, the header won't be in a path known the
pre-processor.
Don't use it project-wide for building everything. Otherwise
symbols for shared modules won't be exposed, e.g. in the
resourceplugin used by the gio resource unit test.
giomodule test needed symbol visibility pragmas added. This is needed on
Windows anyway, so it's better to do it this way rather than disabling
-fvisibility=hidden for the test modules.
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.
Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll and
glib-2.0-0.dll on Windows with MSVC.
Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.
Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
g_build_filename() returns a gchar*, but it was stored in a const gchar*
and then g_free()d, which is wrong and led to a warning about the const
qualifier being cast away.
The g_file_copy() documentation didn't mention if
G_FILE_COPY_ALL_METADATA was applicable or not, and users were led to
call g_file_copy_attributes() to specify it after the g_file_copy()
call, unless they checked the source (been there, done that).
https://bugzilla.gnome.org/show_bug.cgi?id=784037
FreeBSD, DragonflyBSD and NetBSD support O_NOFOLLOW, but they use error
numbers that are different from what POSIX standard specifies. They are
not going to change the behavior, and existing programs on these systems
already take advantage of this difference. To support them, we have to
add a check in GIO to use different error numbers on these systems.
https://bugzilla.gnome.org/show_bug.cgi?id=775593
For historical reasons, the reference dbus-daemon responds to most
method calls on all object paths. However, the canonical path
of the object implementing the o.fd.DBus interface is
/org/freedesktop/DBus, and in some environments (notably AppArmor
with the <abstractions/dbus-session-strict> abstraction) only this
path is allowed.
https://bugs.freedesktop.org/show_bug.cgi?id=101256 officially
deprecates all other object paths, and when adding new APIs we will
only make them available on the canonical object path.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=783593
The caller passes in a GString instance which is then modified by the
function, rather than the function building its own GString and passing
it out to the caller.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783392
For the files in gio/ (but not in gio/ sub-directories), only the *.[ch]
files were handled in commit 3bf4a720c3.
For the modified files in glib/tests/markups/, I've tested that
`make check` still succeeds.
After this commit,
$ git grep -in "GNU Library"
and
$ git grep -in "Library General"
return only results in COPYING files and in glib/libcharset/. The latter
was not updated because it's a copy.
$ git grep -in "version 2" | grep -iv "version 2\.1"
now doesn't return any LGPL license header.
- glib-gettextize.in: GPL
- glib/gen-unicode-tables.pl: GPL
- glib/gnulib/: a copy
- glib/libcharset/: a copy
- m4macros/attributes.m4: GPL
- po/po2tbl.sed.in: GPL
- tap-driver.sh: GPL
- tests/*.pl: GPL
https://bugzilla.gnome.org/show_bug.cgi?id=776504
If g_dbus_unwatch_name() is called from one thread at the same time as
the GDBusConnection is emitting ::disconnected in another thread, there
will be a race and the handler for ::disconnected may end up using
memory after it’s freed.
Fix this by serialising through the map_id_to_client, so that
on_connection_disconnected() atomically gets a strong reference to the
Client, or NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777307
Previously, this was done at the time of spawning the subprocess, which
meant the g_subprocess_launcher_*_environ() functions could not be used
to modify the parent process’ environment.
Change the code to copy the parent process’ environment when
g_subprocess_launcher_set_environ(NULL) is called. Document the change
and add a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Since GtkApplication auto-loads some well-known resource paths. Add a
cross-reference to its documentation. (The cross-reference won’t be
linked if the GTK+ documentation isn’t available at build time, but this
is probably good enough. It is likely to be available.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782336
The OpenURI portal has a separate method to handle local
files now. Use it.
At the same time, split out the openuri helpers into separate
files, and generate code for the OpenURI portal.
https://bugzilla.gnome.org/show_bug.cgi?id=783193
In addition to code, gdbus-codegen can also generate docbook
documentation for DBus interfaces. There's no good reason why
the newly added --output-directory option shouldn't apply to
those generated files as well.
https://bugzilla.gnome.org/show_bug.cgi?id=783201
When we call org.freedesktop.Application.Open to activate
an application and pass file uris, the application may not
be able to see the files due to a flatpak sandbox.
Flatpak puts the flatpak app-id in the X-Flatpak key in
desktop files that it exports, so we can easily recognize
applications that may be affected by this.
In this case, call the document portal to export the files
and pass the resulting uri's instead of the original ones.
https://bugzilla.gnome.org/show_bug.cgi?id=783130
Add $XDG_DATA_HOME/glib-2.0/schemas as a schema source, after (higher
priority than) $XDG_DATA_DIRS/glib-2.0/schemas but before
$GSETTINGS_SCHEMA_DIR. This is per the XDG Base Directory Specification,
which states that user specific versions of data in $XDG_DATA_DIRS can
be created in $XDG_DATA_HOME.
https://bugzilla.gnome.org/show_bug.cgi?id=741335
Currently, all mime types are considered subclasses of
application/octet-stream, but according to the freedesktop
standard, everything but the inode/* types is a subclass of
application/octet-stream.
Update the special case for application/octet-stream so that all
types but inode/* will match with it and add unit test for it.
https://bugzilla.gnome.org/show_bug.cgi?id=782311
g_dbus_connection_call_internal() accesses the user data it passes to
g_dbus_connection_send_message_with_reply() after the call. That data
might be freed already in the case that the callback is called
immediately.
Fix this by removing the 'serial' field from the user data altogether
and fetch the serial from the message in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=748263
mnt_table_is_fs_mounted causes unwanted automount requests due to
canonicalization of source and target. It might be replaced by
mnt_table_find_source as per the documentation in order to prevent
the automounts, but it is redundant. All mtab entries should be already
mounted and thus mnt_table_is_fs_mounted result is always true (it
basically checks that the fs from mtab is in mtab). Let's remove
the check at all.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
libmnt_context is useless. It contains cache which is useful for searching,
but it isn't used in our case. Let's use mnt_context_parse_mtab instead
directly and the mtab processing will be faster.
https://bugzilla.gnome.org/show_bug.cgi?id=781867
The GNetworkMonitor docs were talking about one implementation,
omitting the others. While fixing that, add a bit about implementations
to the GProxyResolver docs too.
When we are inside a sandbox, we want to use the portal
implementation, since it is the only one that has a chance
of working.
This is safe to do, since the portal implementation will
just fail initialization when loaded outside a sandbox.
The flatpak-info file was moved to a different location a while
ago, we should read it from there instead of relying on the
compat symlink. One advantage is that this is a fixed, short
path, we don't have to construct one dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=781826
Looks like the author started typing one thing, then changed their mind
about how to phrase the sentence, and typed something else.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Otherwise, we might end up returning TRUE from
g_app_info_launch_default_for_uri but with a set error parameter. This
will lead to confusing results depending on how the caller checks for
errors. Checking error != NULL indicats the call failed but checking the
return value indicates that it succeeded.
There are a few places where commit 18a33f72 replaced valid (nullable)
(optional) annotations with just (optional). That has a different
meaning.
(nullable) (optional) can only be applied to gpointer* parameters, and
means that both the gpointer* and returned gpointer can be NULL. i.e.
The caller can pass in NULL to ignore the return value; and the returned
value can be NULL.
(optional) can be applied to anything* parameters, and means that the
anything* can be NULL. i.e. The caller can pass in NULL to ignore the
return value. The return value cannot be NULL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some annotations I made while trying to debug bug #781847. They
introduce no behavioural changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Compiling with clang 3.8.1-18 (debian, x86_64) I ran across this
error:
gio-tool.c:40:31: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
message = g_strdup_vprintf (format, args);
^~~~~~
gio-tool.c:55:31: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
message = g_strdup_vprintf (format, args);
^~~~~~
2 errors generated.
To fix the first one, related with the function print_error(), this
patch adds to the function prototype a compiler's attribute.
For the second one, since the usage of that function is to print
one string and the format is already provided, the patch simplifies
the function by no receiving variadic arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=781125
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
The g_drive_is_removable() support was added recently in gio/gvfs
(see Bug 765900 and Bug 765457). It was also added in gvfs-mount,
but we forgot to add it also in gio-tool-mount.
https://bugzilla.gnome.org/show_bug.cgi?id=776169
This patch contains the following changes:
- Print all errors with "gio: " prefix
- Print file uri in error for each tool allowing multiple locations
- Mark all error messages translatable
- Do not leak strings used in error messages
- Always start error messages with capital letter
- Unify some error messages across various tools
- Fix addional/missing new line characters
https://bugzilla.gnome.org/show_bug.cgi?id=776169
Being able to determine that a certificate chain is invalid is not
considered an error, but success. This might not be obvious at first
due to the way the method is named and described currently. Since we
cannot change the name, let's improve the description and clarify this
aspect of its behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=780310
g_dbus_proxy_get_cached_property() and
g_dbus_proxy_get_cached_property_names() can both return NULL if the
property cache is empty. Avoid a crash if this situation arises (which
it looks like it could, from reading the code) by gracefully bailing out
on NULL return values.
Coverity issues: #1257044, #1257045https://bugzilla.gnome.org/show_bug.cgi?id=741229
socket->priv->timeout is only a guint, and the multiplication is
performed before it’s widened to gint64 to be stored in start_time
(thanks, C). This means any timeout of 50 days or more would overflow.
Fixing this bug makes me feel a real sense of self-worth.
Coverity ID: 1159478
Signed-off-by: Philip Withnall <withnall@endlessm.com>
request_completion is checked several blocks higher in the function.
Spotted by Coverity.
Coverity ID: 1373215
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The previously documented requirements for implementing init() and
init_async() as completely idempotent were really quite hard to achieve,
and brought a lot of pain for very little gain. Many implementations of
GInitable and GAsyncInitable did not actually follow the requirements,
or did not correctly handle concurrent init_async() calls.
Relax those requirements so that classes can decide whether their init()
or init_async() implementations need to be idempotent.
https://bugzilla.gnome.org/show_bug.cgi?id=766660
This is effectively the mc-wait-for-name tool from
telepathy-mission-control; moving it in to gdbus-tool will make it more
widely useful without making people depend on telepathy-mission-control
for no other reason. The code here is reimplemented from scratch to use
GDBus.
It blocks until the specified well-known name is owned by some process
on the bus (which can be the session, system, or any other bus). By
passing --activate, the same (or a different) name can be auto-started
on the bus first.
A timeout can be specified to ensure the process doesn’t block forever.
https://bugzilla.gnome.org/show_bug.cgi?id=745971
This will help us break generic GType deadlocks between people using
GDBus in different threads (which is supported), not just by GType
usage in the GDBus thread.
This should fix the common cases we're seeing in the wild, although I
have some lingering concerns that if someone e.g. referenced
e.g. `G_TYPE_DBUS_AUTH_MECHANISM_SHA1` etc. we'd need to add those
too.
https://bugzilla.gnome.org/show_bug.cgi?id=674885
We currently assume that the OpenURI portal should be used
unconditionally when running inside a flatpak sandbox. While
the portal is what we usually want, there are exceptions:
Yelp is now included in the GNOME runtime to allow displaying
help without exporting the user documentation, and the sandboxed
app itself may register a scheme handler.
To account for those cases transparently, always try the normal
code path first and only fall back to calling the portal when
that fails.
https://bugzilla.gnome.org/show_bug.cgi?id=780471
These calls cause race warnings from tsan, but are not a thread safety
problem, because we can only ever observe single bit changes: all
modifications to the GSource.flags field are done with a lock held; all
reads are of independent fields, so no intermediate state can ever be
observed. This assumes that a non-atomic read will consistently give us
an old value or a new value.
In any case, these g_source_is_destroyed() calls can happen from any
thread, and the state could be changed from another thread immediately
after the call returns; so the checks are pointless. In addition,
calling g_source_set_ready_time() or g_source_destroy() on a destroyed
source is not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=778049
Calling the D-Bus method for the OpenURI portal "protects" the logic from
not ever having the remote method running in case the xdg-desktop-portal
process is not yet running and the caller quits quickly after the call.
This should not be a problem as the method returns immediately (regardless
of the user making a selection), but making it synchronous would prevent
situations where the OpenURI method would never be called because of D-Bus
dropping the message after the caller dies, without explicitly waiting for
a reply.
https://bugzilla.gnome.org/show_bug.cgi?id=780441
Actually, Unicode changes to this file got reverted in
2d56c49b10. Also, there is
"No such interface '%s'" string already, so we avoid
breaking the string freeze.
g_subprocess_launcher_spawn() is NULL-terminated, and must have a
non-NULL argv0 specified, so G_GNUC_NULL_TERMINATED is appropriate here.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780032
This highlighted a bug in GDBusConnection, where an interface name was
not included in a message referring to it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=780032
This is an implementation of most of GAppInfo using the OS X
NSBundle APIs.
Missing at this point are things that don't have equivalents
in OS X, such as hidden desktop files, last-used, manual type
associations, and g_app_info_get_all().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
This is an implementation of most of GContentType using the OS X
UTType APIs.
Missing at this point is an implementation of
g_content_types_get_registered() and g_content_type_guess_for_tree().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
Previously, _kh_cancel_sub assumed that it only needed to call
_km_remove if sub did not exist in subs_hash_table. This is erroneous
because the complementary operation, _km_add_missing, can be called
from process_kqueue_notifications, in which context sub can *only* have
come from subs_hash_table.
Since _km_remove is implemented using g_slist_remove, which is
documented to be a noop if the list does not contain the element to be
removed, it is safe to call _km_remove unconditionally here.
https://bugzilla.gnome.org/show_bug.cgi?id=778515
g_settings_schema_source_get_default() is (transfer none), not (transfer
full).
Spotted by Marvin Schmidt.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
On the warning/critical error handling paths for g_settings_set(), the
GVariant value was not ref-sunk, and the schema key was leaked. This
won’t affect code in production (unless it’s seriously buggy), but
eliminates some leaks from the error testing paths in the GSettings
tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
Spotted while running `make check` under Valgrind. While it’s not
necessary to fix memory leaks in glib-compile-schemas (since it’s a
utility which runs briefly then exits), fixing them makes more
legitimate leaks in the Valgrind output more obvious, and means we can
be sure there aren’t leaks in the underlying GLib/GIO code which
glib-compile-schemas is calling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
When unregistered extension point (i.e. NULL pointer) is passed
to `g_io_extension_point_get_extensions`, it causes a segfault.
This commit adds an assertion, to prevent this.
https://bugzilla.gnome.org/show_bug.cgi?id=779183
Happens when the waiting-for-auth state is re-entered:
SERVER_STATE_WAITING_FOR_AUTH
|
v
G_DBUS_AUTH_MECHANISM_STATE_REJECTED
|
v
SERVER_STATE_WAITING_FOR_AUTH
Causing the previous `mech` pointer to get overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=778991
We're first getting the notification by its notify_id, but activating
the action afterwards could redraw it, leading to a dangling pointer.
Fix this by simply searching the list of active notifications again
after activating the action.
GNOME Builder's code was assuming that setting the launcher's
environ to NULL makes the subprocess have an empty environment, but in
fact the parent process's variables are still inherited because execv is
used instead of execve when envp is NULL. This commit clarifies the
documentation to make the behavior clear.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Add filesystem attribute to propagate time, when the metadata for the file
in "recent:///" was last changed. This attribute is needed for sorting
recent backend files in client applications.
https://bugzilla.gnome.org/show_bug.cgi?id=777507
This is small enough that it shouldn't cause problems on most machines
we support, but big enough to increase throughput on a lot of devices
and network protocols.
Note that the actual value is 256k minus malloc overhead, so that it
fits nicely in a 256k block (as suggested by Alexander Larsson).
See https://bugzilla.gnome.org/show_bug.cgi?id=773632https://bugzilla.gnome.org/show_bug.cgi?id=773823
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
When performing the verify and building the error string there were two
possibilities of an infinite loop. The first is the missing twos-complement
to unset the bit in the filtered flags. The second is the lack of handling
G_SUBPROCESS_FLAGS_NONE which can return a valid GFlagsValue (and cannot
unset the bit since the value is zero).
This walks all known values in the GSubprocessFlags type class and check
if they are set. This has the benefit that we don't call needless functions
which walk the same table as well as avoiding mutating values to build
the error string.
https://bugzilla.gnome.org/show_bug.cgi?id=775913
When an invalid hostname is passed for connection, the
g_hostname_to_ascii() might fail when creating the request in
create_request(). Make sure that error is caught and reported rather
than passing "(null)" as the hostname of the site we want to connect to.
https://bugzilla.gnome.org/show_bug.cgi?id=772989
The tests defaultvalue, gdbus-peer and gdbus-unix-addresses will fail
without DBUS, so only run them in case we HAVE_DBUS_DAEMON.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
https://bugzilla.gnome.org/show_bug.cgi?id=767609
WSAWaitForMultipleEvents() only returns for one of the waiting threads, and
that one might not even be the one waiting for the condition that changed. As
such, only let a single thread wait on the event and use a GCond for all other
threads.
With this it is possible to e.g. have an UDP socket that is written to from
one thread and read from in another thread on Win32 too. On POSIX systems this
was working before already.
https://bugzilla.gnome.org/show_bug.cgi?id=762283
-2LL<<34 is undefined, because left-shifting a negative number is
undefined (it was implementation-defined behaviour in C99, but
is formally undefined in C11). The undefined behaviour sanitizer
picks this up.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
_g_dbus_auth_mechanism_server_data_send may fail in which case
we would endup getting a NULL data. In this case we should not
try to encode the data and simply let the state machine to continue.
The auth mechanism will change internally to REJECTED so we just
need to continue the iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=775309
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
If g_socket_receive_message_with_timeout() is called with messages ==
NULL set the msg_control buffer to empty to not request the control
messages from recvmsg() at all.
This completely disables the control message processing and reduces
overhead, which might be critical at high packet rate.
https://bugzilla.gnome.org/show_bug.cgi?id=774520
This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
I'm guessing the developments were done in 2.44 but the patches landed
after the 2.45.0 bump without an update to the Since tags.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769630
GLib has g_unix_mount_at (mount_path) already, let's add g_unix_mount_for
(file_path) for whatever path. GLib already contains some private code
for such task. Let's make this code public. This functionality is needed
by GVfs (see Bug 771431) in order to avoid copy-and-pasting.
https://bugzilla.gnome.org/show_bug.cgi?id=772160
There have been some improvements to the tool recently, but it's hard to
know if those are available on a given system unless the tool provides a
--version commandline option.
https://bugzilla.gnome.org/show_bug.cgi?id=772269
It only works through its virtual methods, so while it could be
instantiated before (and this is technically an API break), any instance
of it would previously have crashed as soon as any of its methods were
called anyway.
If anybody has any problems with this ABI break, please make them known
during the 2.51 unstable development cycle and it can be reverted.
https://bugzilla.gnome.org/show_bug.cgi?id=772255
/proc/self/mountinfo is used to monitor changes of mounts with libmount.
However, GFileMonitor is used currently to monitor this file, which
doesn't work and consequently "changed" signal is never emitted. Special
monitoring needs to be used instead, same as it is used for /proc/mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=662946
People might put more extraneous whitespace in a @since line in a
documentation comment, which should not affect the ordering of
methods/signals/etc. in the generated output.
https://bugzilla.gnome.org/show_bug.cgi?id=770372
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller in
https://bugzilla.gnome.org/show_bug.cgi?id=745754
The changes in this patch, compared to his are to always return
the hash table with file information from parse_resource_file, so
we can use it for dependency output, regardless if generate_dependencies
was TRUE or not.
Add --dependency-file=foo.d option to generate a gcc -M -MF style
dependency file for other build tools. The current output of
--generate-dependencies is only useful for use directly in Makefile
rules, but can't be used in other build systems like that.
The generated dependency file looks like this:
$ glib-compile-resources --sourcedir= test.gresource.xml --dependency-file=-
test.gresource.xml: test1.txt test2.txt test2.txt
test1.txt:
test2.txt:
test2.txt:
Unlike --generate-dependencies, the --dependency-file option can be
used together with other --generate options to create dependencies
as side-effect of generating sources.
Based on a patch by Tim-Philipp Müller.
https://bugzilla.gnome.org/show_bug.cgi?id=745754
Previously, this would not work, as it would result in comparing the
order of a string and an integer. Make it work, and make 'UNRELEASED'
compare higher than other versions so it's always treated as the latest
version.
'UNRELEASED' is commonly used by maintainers to highlight new API while
it's being prototyped, until they know which version it will actually
be released in. At the time of release, they replace all 'UNRELEASED'
strings in git with the new version number.
An example of this usage is here:
d380ac6a2a (9208ee267cb05db1afd3a5c323d71e51db489447_7619_7656)https://bugzilla.gnome.org/show_bug.cgi?id=769995
gcc 6 warns (fatally, by default) that %c only uses a 2-digit year
in some locales. The precise format does not seem to be important
for this sample code, so use ISO 8601 instead of suppressing the
warning with a pragma.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768453
At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
GDatagramBased allows connection-oriented and connection-less sockets,
but does not allow stream-based sockets (because it’s datagram-based).
So it supports SCTP and UDP, but not TCP.
Clarify that in the documentation, and people sometimes confuse
connection-oriented with stream-based, due to the prevalence of TCP.
Use mnt_context_get_mtab instead of using mnt_context_get_table(), since
that's the recommended way of accessing mtab/mountinfo information, and
also because that way the (struct libmnt_table *) will get automatically
deallocated when calling mnt_free_context()
https://bugzilla.gnome.org/show_bug.cgi?id=769238
g_socket_listener_add_address() is synchronous; all of the events will
have been emitted before it returns and it doesn't queue any sources.
The test was unintentionally depending on the fact that
g_main_context_iterate(NULL, TRUE) would return anyway (at least the
first time it was called), but that's no longer true after e4ee307.
https://bugzilla.gnome.org/show_bug.cgi?id=768968
glib-compile-resources --generate is supposed to automatically detect
whether to generate source code or header from the target's file extension.
However, this only worked for C; extend this to include the canonical
C++ filename extensions. Also make the check case insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=747134
Include the filename for the file in question in many of the
error messages in glocalfile.c. This is useful information when
diagnosing such errors, so make it easily available.
http://bugzilla.gnome.org/show_bug.cgi?id=754012
The recently-added GIO tools is intended to be built on all platforms, so
adjust the code a bit to enable this:
-Use gssize instead of ssize_t, as ssize_t is not supported by all
compilers.
-Include io.h on Windows, and define STDIN_FILENO and STDOUT_FILENO if
necessary on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=768357
Ensure that @key is non-%NULL on g_settings_reset().
It turns out that using g_settings_reset() with %NULL key (although
invalid as per the API documentation and not possible via bindings)
accidentally produces the same effect as the _reset_all() API that we
are about to add.
Add the standard precondition checks to prevent that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=744678
GSettings objects were not unreffed in test_flags, test_enums and
test_ranges tests and when we skip internationalization tests, ie
test_l10n(_context).
https://bugzilla.gnome.org/show_bug.cgi?id=768560
The two known use-cases for autolaunching are:
* X-forwarding: "ssh -Y myhost myapp" resulting in a
session bus on myhost but an X server on the original host
* Legacy desktop environments on OSs without D-Bus integration:
e.g. running a single GNOME or KDE app under fvwm or something,
without a session dbus-daemon being started by either systemd,
gnome-session, or OS integration scripts analogous to Debian's
/etc/X11/Xsession.d/75dbus_dbus-launch
In either case, an X11 DISPLAY is also needed.
"dbus-launch --autolaunch" doesn't do anything useful when unable
to connect to an X11 display; this has been the case since the feature
was added in 2006, and is useful to avoid "split brain" situations in
which two processes that ought to be part of the same session end up
on separate session buses. Since dbus commit 407c111 in 2011,
libdbus hasn't even attempted to run "dbus-launch --autolaunch"
unless getenv("DISPLAY") returns non-null in the parent: this avoids
doing a relatively complicated fork-and-exec that is clearly not
going to lead to success. This commit gives GDBus the same policy.
This change was originally made to work around a race condition in
subprocess spawning (Debian bug #737380, GNOME bug #711090) but
it seems valid in its own right.
In my opinion as D-Bus maintainer, "dbus-launch --autolaunch" should
be considered to be an X11 feature, and any future D-Bus enhancements
(e.g. kdbus) or successors for X11 (e.g. Wayland, Mir) should obtain
a session bus address by other means - either a session manager
such as "systemd --user", gnome-session or Upstart, or a wrapper
for the user session like dbus-run-session(1).
Related to dbus bug <https://bugs.freedesktop.org/show_bug.cgi?id=19997>.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723506
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737380
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
xdg-desktop-portal support is only usable on *NIX platforms, so don't build
them on non-*NIX platforms. Also clean up gio/Makefile.am a bit to split out
the listings for the platform-specific sources from the platform-neutral
sources, and assemble them for the final list of sources required for libgio.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
OS X apparently stringifies the IPv6 address "::80" as "::0.0.0.128",
which is bizarre, but that address *is* in a "reserved for future use"
range, so it's not unambiguously wrong I guess. Anyway, fix the text
to use an address everyone can agree on.
https://bugzilla.gnome.org/show_bug.cgi?id=768551
The backend for this lives in xdg-desktop-portal,
and is in turn using GNetworkMonitor.
When network is not available in the sandbox, there is
no point in reporting accurately about the network
status outside the sandbox. Just return 'no connection'
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
We need to patch in the portal support at a high enough
level that GAppInfo is not involved - a sandboxed app may
not be able to see any applications, so it can only launch
the defaults.
Note that even though the API is called launch_default...,
the portal may still offer the user to choose the application
to launch.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
These are private helper functions that will be used in
the following commits to get information about whether
we are running in a flatpak sandbox, etc.
We allow the use of GTK_USE_PORTAL=1 in the environment
to force the use of portals. This can be useful for
testing and debugging portal interaction.
https://bugzilla.gnome.org/show_bug.cgi?id=768498
This command collects the various commandline utilities that
are currently shipped in gvfs, and unifies them under a single,
command-style binary.
The tools just use GIO APIs, so it makes sense for them to live here.
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
The list of supported schemes is not known at compile-time, so it is
wrong to iterate the list with G_N_ELEMENTS() and we miss all but the
first scheme. Fix by checking for the %NULL sentinel instead.
https://bugzilla.gnome.org/show_bug.cgi?id=768119
Add filesystem attribute to detect remote filesystems in order to
replace hardcoded filesystem types in GtkFileSystem. Set this attribute
also for GLocalFile appropriately.
Bump version to 2.49.3, so that early adopters of new API have a version
number to target.
If none of the closures in the hash table return a non-null value, the
loop never ends. Since the end of the hash table has been reached at
that point, g_hash_table_iter_next() starts asserting.
The possible fix is making the return value of g_hash_table_iter_next()
the condition in the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=768029
Add a new API to allow clients to register a custom GFile implementation
handling a particular URI scheme.
This can be useful for tests, but also for cases where a different URI
scheme is desired to be used with another custom GFile backend.
As an additional cleanup, we can use this to register the "resource" URI
scheme too.
Based on a patch by Jasper St. Pierre <jstpierre@mecheye.net>.
https://bugzilla.gnome.org/show_bug.cgi?id=767887
5cea1c861d introduced accessors for 64bit
ints to gsettings, at which point the testcases were expanded.
Unfortunately, the expanded tests contained a bug: integer constants
passed to g_object_set() for a 64-bit property need an up-cast. Add
that now.
Problem found by Iain Lane.
If a backup file is created, opened successfully, then fstat() on it
fails (perhaps due to another process deleting it in the mean time?),
the FD will be leaked.
Coverity issue: #1159485https://bugzilla.gnome.org/show_bug.cgi?id=730187
Previously this would cause an assertion failure when checking the paths
of exported objects, as it would try to check that their paths started
with ‘//’ due to mishandling the root object case.
Includes a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=761810
proxy->priv->name_owner gets overwritten in async_init_data_set_name_owner() on the
assumption that it will always be NULL when we get there. However,
on_name_owner_changed() can run first, and it does set name_owner.
==20126== 42 bytes in 6 blocks are definitely lost in loss record 15,174 of 48,256
==20126== at 0x4C280F3: malloc (vg_replace_malloc.c:299)
==20126== by 0x7541D00: g_malloc (gmem.c:104)
==20126== by 0x7558FEE: g_strdup (gstrfuncs.c:364)
==20126== by 0x6DF8E4F: on_name_owner_changed (gdbusproxy.c:1399)
==20126== by 0x6DE94C4: emit_signal_instance_in_idle_cb (gdbusconnection.c:3743)
==20126== by 0x753C315: g_main_dispatch (gmain.c:3066)
==20126== by 0x753C315: g_main_context_dispatch (gmain.c:3642)
==20126== by 0x753C667: g_main_context_iterate.isra.24 (gmain.c:3713)
==20126== by 0x753CA69: g_main_loop_run (gmain.c:3907)
==20126== by 0x5E38000: meta_run (main.c:556)
==20126== by 0x401EC0: main (main.c:441)
https://bugzilla.gnome.org/show_bug.cgi?id=755439
This fixes a build failure in Continuous that resulted in the error:
../../../gio/tests/test.gresource.xml: Failed to locate
'test-generated.txt' in any source directory.
Makefile:4676: recipe for target 'test.gresource' failed
make[6]: *** [test.gresource] Error 1
Nautilus wants to show entries in the sidebar only for removable devices.
It uses currently sort of conditions to determine which devices should be
shown. Those condition fails in some cases unfortunatelly. Lets provide
g_drive_is_removable() which uses udisks Removable property to determine
which devices should be shown. It should return true for all drives with
removable media, or flash media, or drives on usb and firewire buses.
https://bugzilla.gnome.org/show_bug.cgi?id=765900
This prevents testsuite from trying to build any TESTS in that
subdirectory, which will fail, because there are no TESTS defined
in that Makefile.am.
This happens when user runs make check TESTS=...
https://bugzilla.gnome.org/show_bug.cgi?id=766407
This adds a new --c-generate-autocleanup option to gdbus-codegen
which can be used to instruct gdbus-codegen about what autocleanup
definitions to emit.
Doing this unconditionally was found to interfere with existing
code out in the wild.
The new option takes an argument that can be
none, objects or all; to indicate whether to generate no
autocleanup functions, only do it for object types, or do it
for interface types as well. The default is 'objects', which
matches the unconditional behavior of gdbus-codegen on the 2.48
branch.
https://bugzilla.gnome.org/show_bug.cgi?id=763379
The use of past tense in g_task_had_error makes one assume that it
won't forget about any errors that might have occurred. Except, in
reality, it would.
Let's use a boolean flag to remember the error once it's been
propagated, as opposed to keeping the error around. This ensures that
the g_task_propagate_* methods continue to give invalid results when
called more than once, as mentioned in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=764163
Some GNOME projects unconditionally work around the generated code's
lack of g_autoptr support by defining the autoptr cleanup function
themselves, which is not forward-compatible; as a result, commit
cbbcaa4 broke them. Do not define the cleanup function unless the
including app "opts in" to newer APIs via GLIB_VERSION_MAX_ALLOWED.
Projects requiring compatibility with GLib < 2.49 can get a
forward-compatible g_autoptr for a generated GInterface type found in
a library, for example ExampleAnimal in the GIO tests, by declaring
and using a typedef with a distinct name outside the library's
namespace:
typedef AutoExampleAnimal ExampleAnimal;
G_DEFINE_AUTOPTR_CLEANUP_FUNC (AutoExampleAnimal, g_object_unref)
...
g_autoptr (AutoExampleAnimal) animal = NULL;
/* returns ExampleAnimal * */
animal = example_animal_proxy_new_sync (...);
/* takes ExampleAnimal * first argument */
example_animal_call_poke_sync (animal, ...);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=763379
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
The rest of the generated classes gained g_autoptr support in fd6ca66,
but this one is still missing. Because whatever_proxy_new_finish() and
whatever_proxy_new_sync() are declared as returning a Whatever *
instead of a WhateverProxy *, and the generated method-call stubs
act on a Whatever *, it's reasonably common to want to declare a
g_autoptr (Whatever).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/review?bug=763379
Reviewed-by: Colin Walters <walters@verbum.org>
gdbus-tool prints a hint about the expected arguments to a function call
in case of errors. Unfortunately, it prints this message on all errors.
I've seen this confuse users several times -- they go on tweaking the
arguments trying to get the correct type, even though they had it
correct in the first place.
Let's limit the hint to the case where it was actually invalid arguments
that triggered the problem. Also, adjust the code that prints the
message so that it will also report on the case that no arguments were
expected.
We could possibly get closer to what we want by comparing the list of
expected arguments with the parameter list, as it was parsed from the
user, but that would involve composing the expected type. Let's keep
this simple for now.
https://bugzilla.gnome.org/show_bug.cgi?id=765710
When debugging a program or testing a change to an installed version, it
is often useful to be able to replace resources in the program or a
library, without recompiling.
To support this, for debugging and hacking purposes, it's now possible
to define a G_RESOURCE_OVERLAYS environment variable as a
colon-separated list of substitutions to perform when looking up
GResources.
A substitution has the form
"/org/gtk/libgtk=/home/desrt/gtk-overlay"
The part before the '=' is the resource subpath for which the overlay
applies. The part after is a filesystem path which contains files and
subdirectories as you would like to be loaded as resources with the
equivalent names.
In the example above, if an application tried to load a resource with
the resource path '/org/gtk/libgtk/ui/gtkdialog.ui' then GResource would
check the filesystem path '/home/desrt/gtk-overlay/ui/gtkdialog.ui'. If
a file was found there, it would be used instead.
Substitutions must start with a slash, and must not have a trailing
slash before the '='. It is possible to overlay the location of a
single resource with an individual file.
https://bugzilla.gnome.org/show_bug.cgi?id=765668
Replace the hand-written equivalent of this with the call to the
GHashTable built-in version to save a few lines of code.
The GResource code was written a couple of years before this function
existed.
Similarly, replace a set-mode usage of g_hash_table_insert() with a call
to g_hash_table_add().
https://bugzilla.gnome.org/show_bug.cgi?id=765668
GContextSpecificGroup has been somewhat broken for a rather long time:
when we remove the last reference on an object held in the group, we try
to clean up the source, but fail to actually remove it from the
mainloop.
We will soon stop emitting signals on the source (due to it having been
removed from the hash table) but any "in flight" signals will still be
delivered on the source, which continues to exist. This is a problem if
the event is being delivered just as the object is being destroyed.
This also means that we leave the source attached to the mainloop
forever (and next time will create a new one)...
This is demonstrated with the GtkAppChooser dialog which writes an
update to the mimeapps.list file just as it is closing, triggering the
app info monitor to fire just as it is being destroyed.
Karl Tomlinson correctly analysed the problem and proposed this fix.
https://bugzilla.gnome.org/show_bug.cgi?id=762994
GApplication has accepted any valid bus name as an application ID since
before the time of D-Bus activation. This includes bus names with '-'.
Several applications have even attempted support bus activation with
these names, going as far as installing D-Bus service files, without
realising that they are silently falling back to fork()/exec() on
account of the name containing a dash.
The reason for the problem is that D-Bus object paths cannot contain
dashes. We solved this problem privately in an unspecified way inside
of GApplication but substituting '_' in this case, but never made this
part of the Desktop Entry Specification.
The fact that these apps with '-' in the desktop file names aren't
actually using D-Bus activation is beside the point: their intent here
was clear. Let's avoid forcing them to rename their desktop files again
by simply accepting '-' in desktop file names and munging the path in
the way that GApplication did so historically.
The new path escaping code here has been copied more or less verbatim
from GApplication's own code for the same purpose, with only the removal
of one irrelevant part.
An update to the desktop entry specification will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=764754
This was confusing some static analysis. Through canonicalize_filename()
at construction time, we guaranteed that ->filename is canonical and
absolute, so g_path_skip_root() should never fail.
https://bugzilla.gnome.org/show_bug.cgi?id=731988
This ensures that the generated file is always the same (not dependent
on the build machine's environment), making the build reproducible.
Thanks to Jérémy Bobbio <lunar@debian.org> for the Debian bug report and
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=763617
Even though GetStartupInfo() in g_win32_run_session_bus() would
tell us that STARTF_FORCEONFEEDBACK flag is not set, it still
affects the rundll32 process for some reason.
This means that Windows WM changes mouse cursor to IDC_APPSTARTING for
a few seconds when rundll32 runs g_win32_run_session_bus(). Since
g_win32_run_session_bus() never satisfies the conditions set by
STARTF_FORCEONFEEDBACK, the busy cursor only goes away after a
timeout.
Fix this by explicitly running GetMessage(). To ensure that GetMessage()
doesn't block, post a quit message immediately before calling it.
https://bugzilla.gnome.org/show_bug.cgi?id=760694
Some applications support running in a mode where they present
themselves as a different application to the user (for example web
browsers or terminals).
To facilitate this, add an option --gapplication-app-id which allows
users to override an application's id from desktop files or similar.
Applications need to opt-in to this by setting the
G_APPLICATION_CAN_OVERRIDE_APP_ID flag.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
currently schema_list will iterate over the default SchemaSource
list, and not the one associated with the passed in Schema. This
means schema_list can give incorrect results for a Schema fetched
from a non-default SchemaSource, like via new_from_directory.
https://bugzilla.gnome.org/show_bug.cgi?id=757506
Perform conversion before writing a value out of the cache into the registry,
and convert back when reading a value into the cache out of the registry.
The registry holds UTF-8 strings.
This is a flag used to understand if a key exists on the registry
and if it is readable. It makes more sense to rename it as readable
since anyway a key that does not exists anymore is a key that is
not readable.
The documentation of g_file_info_copy_into() was misleading. The
attributes are not just copied, @dest_info is also cleared at the
beginning. So any previously set attributes in @dest_info are lost.
There was a bug in gedit about this function, where some metadata were
not saved. So it might make sense to change the implementation to not
clear @dest_info, and copy one by one the attributes from @src_info to
@dest_info.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
I'm tired of seeing 'No such file or directory' in the logs without
a hint as to what is actually wrong. Including the filename here
may help me tracking down a bug in the continuous infrastructure.
Visual Studio, at least the older versions, cannot use L on macros which
are defined as a constant string, plus the L must be applied to all string
literals here. This does not look nice, but this is life...
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
Add a new GDtlsConnection interface, plus derived GDtlsClientConnection
and GDtlsServerConnection interfaces, for implementing Datagram TLS
support in glib-networking.
A GDtlsConnection is a GDatagramBased, so may be used as a normal
datagram socket, wrapping all datagrams from a base GDatagramBased in
DTLS segments.
Test cases are included in the implementation in glib-networking.
https://bugzilla.gnome.org/show_bug.cgi?id=752240
We changed the behaviour of this API to adapt to a change in the D-Bus
specification. Document the new behaviour, along with the time of the
change.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
gdbus sets NO_REPLY_EXPECTED when no callback is given to
g_dbus_connection_call(). It makes sense that it also handles the server
side correctly by discarding replies to clients that don't want one.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
I think it is a recursion from the GUnixMountMonitor constructor, to a
GLocalFileMonitor on /etc/fstab, and into GUnixMountMonitor again, now
with a mutex already held, so it deadlocks.
https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=235354
That mutex in glocalfile.c:g_local_file_find_enclosing_mount() doesn't
seem necessary any more IMHO. Inside it, only 'mount' is modified, but
that's just a stack variable local to this function. When
klass->get_mount_for_mount_path is called, it's given one const
parameter and the other is unused, so they're unchanged. 'klass'
doesn't seem it could be modified either inside that function.
It doesn't recurse infinitely, but seems to work correctly and pass the
testsuite after this change.
The FreeBSD project already applied my patch in their ports tree, and
their users seem happy with it.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712848#64
and https://bugzilla.gnome.org/show_bug.cgi?id=753378
As g_win32_get_command_line() calls CommandLineToArgvW() to acquire the
arguments passed into a GApplication program, it actually returns the
whole command line which is used to invoke the program, including the
script interpreter and its flags when a script using GNOME bindings
(e.g. PyGObject and so on) is being invoked.
The issue here is that g_application_run() would most probably have
trouble in the scripts scenario on Windows as it is likely unable to
"recognize" the script interpreter, causing such scripts to fail to run.
Largely based on the patch by Ray Donnelly <mingw.android@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=734095
Otherwise, we'll acquire it on every loop iteration, which can leave us
vulnerable to racing another thread for the acquisition of the main
context.
This can break methods like g_main_context_invoke, which try to acquire
a context to figure out if it can invoke the method synchronously or
need to defer to an idle. In these cases, it isn't guaranteed that the
invocation function will be invoked in the default main context,
e.g. the one that GApplication is holding.
This also matches what GMainLoop is doing.
https://bugzilla.gnome.org/show_bug.cgi?id=752983
* On W32 use a real directory (SYSTEMROOT) instead of '/etc/'
* Disable test_symbolic_icon() as it can't be passed (symbolic icons are not
really supported)
* PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves
the entires (both have the same priority)
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
As per #578363, "if one requests e.g. strings via GOptionEntry.arg_data
then those are strduped and needs to be free'ed by the application."
Fixes following leak:
=================================================================
==29426==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 10 byte(s) in 1 object(s) allocated from:
0 0x7f3ab783d37a in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9437a)
1 0x7f3ab70f7c82 in g_malloc /home/lebedevri/src/glib/glib/gmem.c:94
2 0x7f3ab70f7f60 in g_malloc_n /home/lebedevri/src/glib/glib/gmem.c:330
3 0x7f3ab713258e in g_strndup /home/lebedevri/src/glib/glib/gstrfuncs.c:425
4 0x7f3ab709c86b in strdup_len /home/lebedevri/src/glib/glib/gconvert.c:864
5 0x7f3ab709c966 in g_locale_to_utf8 /home/lebedevri/src/glib/glib/gconvert.c:905
6 0x7f3ab7103c32 in parse_arg /home/lebedevri/src/glib/glib/goption.c:1276
7 0x7f3ab71066fb in parse_long_option /home/lebedevri/src/glib/glib/goption.c:1670
8 0x7f3ab7108047 in g_option_context_parse /home/lebedevri/src/glib/glib/goption.c:1997
9 0x408532 in main /home/lebedevri/src/glib/gio/glib-compile-resources.c:629
10 0x7f3ab6c72b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
https://bugzilla.gnome.org/show_bug.cgi?id=757299
It's theoretically possible (and see in the wild) for D-Bus messages to
come in to the application after shutdown() has been called and while
we're draining out the lingering events in the main context.
Prevent this from happening by ensuring we unregister our objects on
D-Bus during the shutdown process.
https://bugzilla.gnome.org/show_bug.cgi?id=757372
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
Commit 8ece2de964 transplanted a block of
code that contained an early-exit-on-error case which freed several
variables.
Because of the move, the normal-path unconditional free of one of these
variables is now above this early exit case, so if this block is hit, it
will now be a double-free.
Remove that.
https://bugzilla.gnome.org/show_bug.cgi?id=757693
It was removed, apparently accidentally, in commit 5b48dc4.
This had the side-effect that it wasn't included in tarball releases,
which means that commit ab7b4be doesn't work when building a package.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=734469
Reviewed-by: Colin Walters <walters@verbum.org>
The new "slowly add more task threads" code doesn't fully deal with
apps that queue lots and lots of tasks which then block on tasks from
their task threads. Fix this by bringing back the "task is blocking
other task" check and making sure that such tasks get bumped to the
front of the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
Recent changes to file monitors removed the delay before events were
reported. Among other things, this caused the trash backend of gvfs to
notice trashed files sooner than before.
On noticing trashed files, the backend tries to read the info file to
discover (among other things) the original location of the file.
Unfortunately, g_local_file_trash() does a strange dance when trashing a
file. It does a loop of open(O_EXCL) in order to file an empty filename
in the trash to write an info file to, trashes the file, and only then
writes the contents of the info file. This means that at the time the
file is moved to the trash, the info file is an empty stub.
Change the order so that we write out the actual content of the info
file first. If the actual trash files then we will unlink the info file
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=749314
Add string serialisation functions for GNetworkAddress, GSocketAddress,
GUnixSocketAddress, GInetSocketAddress, GNetworkService and
GSocketConnectable. These are intended for use in debug output, not for
serialisation in network or disc protocols.
They are implemented as a new virtual method on GSocketConnectable:
g_socket_connectable_to_string().
GInetSocketAddress and GUnixSocketAddress now implement
GSocketConnectable directly to implement to_string(). Previously they
implemented it via their abstract parent class, GSocketAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=737116
GDatagramBased is an interface abstracting datagram-based communications
in the style of the Berkeley sockets API. It may be contrasted to (for
example) GIOStream, which supports only streaming I/O.
GDatagramBased allows socket-like communications to be done through any
object, not just a concrete GSocket (which wraps socket()).
This adds the GDatagramBased interface, and implements it in GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
When G_OUTPUT_STREAM_CLOSE_TARGET is set,
g_output_stream_real_splice was not returning -1 in any error
cases, since the success flag was being overwritten.
https://bugzilla.gnome.org/show_bug.cgi?id=756255
The environment variable DISPLAY makes sense only for X11, it should
not be set in gio.
Beside, if the backend is not X11 but Wayland, forcing the value of
DISPLAY to the Wayland display will confuse the backend selection and
possibly crash the applications.
https://bugzilla.gnome.org/show_bug.cgi?id=754983
Commit a0cefc2217 introduced an unresolved
symbol, g_socket_send_message_with_timeout(), on win32. Windows
unfortunately isn’t clever enough to fill in the gaps and magic up the
implementation of that function from nowhere, so we had better do it
ourselves.
Factor the blocking behaviour out of g_socket_send_message() into a new
internal g_socket_send_message_with_timeout().
https://bugzilla.gnome.org/show_bug.cgi?id=756054
5d68947 factored out resuable items, but some of these are only for
*NIX builds, which will break the build on Windows. Fix this by
building these portions only when !G_OS_WIN32.
https://bugzilla.gnome.org/show_bug.cgi?id=756053
The value of g_socket_is_connected() gets stuck high if the GSocket is
shut down in two steps:
g_socket_shutdown (socket, TRUE, FALSE, NULL);
g_socket_shutdown (socket, FALSE, TRUE, NULL);
rather than one:
g_socket_shutdown (socket, TRUE, TRUE, NULL);
Fix that by tracking the connected status for the read half and the
write half of the connection separately.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
set_auth_msg() was returning FALSE to indicate error, but all its
callers were expecting a negative return value to indicate error. This
was causing memory leaks for the GError, and errors to not be reported.
Coverity CID: 1325357
If the certificate constructor is called as:
g_tls_certificate_new_from_pem (data, length, NULL);
and PEM parsing fails for the private key, the function would have
continued to try and create a certificate using a NULL key_pem value,
which would have failed or crashed.
Use g_propagate_error() correctly to avoid this.
Coverity CID: 1325403
If an error in the underlying sendmmsg() syscall occurs after
successfully sending one or more messages, g_socket_send_messages()
should return the number of messages successfully sent, rather than an
error. This mirrors the documented sendmmsg() behaviour.
This is a slight behaviour change for g_socket_send_messages(), but as
it relaxes the error reporting (reporting errors in fewer situations
than before), it should not cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
In order to support per-operation timeouts on new API like
g_socket_receive_messages(), the internal GSocket API should use
timeouts rather than boolean blocking parameters.
(timeout == 0) === (blocking == FALSE)
(timeout == -1) === (blocking == TRUE)
(timeout > 0) === new behaviour
https://bugzilla.gnome.org/show_bug.cgi?id=751924
This complements the GOutputMessage struct. It will shortly be used for
adding a g_socket_receive_messages() function, but needs to be committed
first to allow some internal refactoring of GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Previously, GLib returned text/plain for empty files.
This is important because people may want to open empty (eg:
just-created) text files with the text editor.
An unintended side-effect of b6fc1df022
caused GLib to start returning application/octet-stream instead of
text/plain for these files.
This commit is essentially a revert of that commit, with a different
solution: we move the special-case up a bit in the function and
hard-code it to text/plain.
This change does not exactly maintain the old behaviour: previously, a
"fast" lookup would have returned application/octet-stream on an empty
file and now it will return text/plain. I consider this to be an
improvement (since we're returning better data) and don't expect it to
cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=755795
The API design here is a bit awkward — the in/out flags argument should
actually have been an in flags argument and an out msg_flags argument.
Clarify that a bit in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
_wstat32i64() doesn't exist in msvcrt.dll. This doesn't cause a problem
on 32-bit Windows because mingw-w64 #defines _wstat32i64 to _wstati64,
but on 64-bit Windows we get a link error.
In addition, _wstat32i64() takes a struct _stat32i64 *, but
GLocalFileStat is #defined to struct _stati64, which is not the same
type on 64-bit Windows.
Fix by using _wstati64().
https://bugzilla.gnome.org/show_bug.cgi?id=749161
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
