The list is sorted in ascending order, which means that to put
verbs alphabetically we need to sort ealier verbs with -1. Same for
the "open" verb and the preferred verb (if any).
* UWP apps that have low registry footprint might end up with chosen_handler == NULL.
Ensure that this doesn't happen.
* UWP apps don't need verbs for URIs, but we do need verbs to have a link to an app
(since handlers don't contain app fields). Work around this by adding an "open" verb
to each UWP URI handler.
* Duplicate the code that inserts extension handler verbs into the app to also insert
URI handler verbs. This allows URI-only apps to be used correctly later on (otherwise
GLib errors out, saying that the app has no verbs).
Use pretty name as the result of _name(), if available. This is
more in line with what .desktop files return. Canonical name
may be completely unintelligible.
MSDN doesn't say much on this subject, but i've seen apps in the wild
that have the "shell" subkey with verbs *either* in the root app key *or*
in the "Capabilities" subkey of the root key. Accommodate either case by trying both
(root key gets a priority, since this is how MS Address Book is registered -
assume that MS knows how to do this the right way).
This function enumerates all user-accessible UWP packages
and calls the user-provided callback for each package.
This can be used to make GLib aware of the UWP applications
installed in the system.
The function works by using IPackageManager/IPackage UWP interfaces
and XmlLite COM library to parse package manifests.
The function requires COM, and initializes it to a single-thread
appartment model. To ensure this doesn't break anything, either
only use it in a separate thread (COM is initialized on a per-thread
basis), or make sure that the main thread also uses the same COM
model (it's OK to initialize COM multiple times, as long as the same
model is used and as long as init/uninit calls are paired correctly).
MinGW-w64 lacks the appropriate headers, so we have to add them
here. Note that these only have the C versions (normally these
things come in both C and C++ flavours), since that's what we use.
Also note that some of the functions that we don't use (but must
describe to maintain binary compatibility) were altered to use
IUnknown (basically, an untyped pointer) instead of the appropriate
object types, as adding these types would require other types,
which would pull even more types, forcing us to drag half of the
UWP headers in here. By replacing unused types with IUnknown we
can trim a lot of branches from the dependency graph.
This is a COM object that implements IStream by using a HANDLE
and WinAPI file functions to access the file (only a file; pipes
are not supported). Only supports synchronous access (this is
a feature - the APIs that read from this stream internally will
never return the COM equivalent of EWOULDBLOCK, which greatly
simplifies their use).
Just embed a PNG instead. gdk-pixbuf deprecated its pixdata support in
version 2.32, in 2015.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1281
gio/gcredentials.c: In function ‘g_credentials_to_string’:
gio/gcredentials.c:238:31: error: comparison of integer expressions of different signedness: ‘uid_t’ {aka ‘unsigned int’} and ‘int’
238 | if (credentials->native.uid != -1)
| ^~
gio/gcredentials.c:240:31: error: comparison of integer expressions of different signedness: ‘gid_t’ {aka ‘unsigned int’} and ‘int’
240 | if (credentials->native.gid != -1)
| ^~
gio/gfileattribute.c: In function ‘escape_byte_string’:
gio/gfileattribute.c:286:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’}
286 | for (i = 0; i < len; i++)
| ^
gio/gfileattribute.c:299:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’}
299 | for (i = 0; i < len; i++)
| ^
gio/gicon.c: In function ‘g_icon_to_string_tokenized’:
gio/gicon.c:165:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
165 | for (i = 0; i < tokens->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_remove_attribute’:
gio/gfileinfo.c:706:9: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
706 | if (i < info->attributes->len &&
| ^
Fix signedness warning in gio/gfileinfo.c:g_file_info_create_value()
gio/gfileinfo.c: In function ‘g_file_info_create_value’:
gio/gfileinfo.c:1084:9: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
1084 | if (i < info->attributes->len &&
| ^
Fix signedness warning in gio/gfileinfo.c:matcher_matches_id()
gio/gfileinfo.c: In function ‘matcher_matches_id’:
gio/gfileinfo.c:2624:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
2624 | for (i = 0; i < matcher->sub_matchers->len; i++)
| ^
Fix signedness warnings in gio/gfileinfo.c:g_file_attribute_matcher_enumerate_namespace()
gio/gfileinfo.c: In function ‘g_file_attribute_matcher_enumerate_namespace’:
gio/gfileinfo.c:2713:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
2713 | for (i = 0; i < matcher->sub_matchers->len; i++)
| ^
gio/gfileinfo.c:2715:27: error: comparison of integer expressions of different signedness: ‘guint32’ {aka ‘unsigned int’} and ‘int’
2715 | if (sub_matchers[i].id == ns_id)
| ^~
Fix signedness warning in gio/gfileinfo.c:g_file_attribute_matcher_enumerate_next()
gio/gfileinfo.c: In function ‘g_file_attribute_matcher_enumerate_next’:
../glib.git/gio/gfileinfo.c:2752:13: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’} [-Werror=sign-compare]
2752 | if (i < matcher->sub_matchers->len)
| ^
gio/gfileinfo.c: In function ‘g_file_info_list_attributes’:
gio/gfileinfo.c:645:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
645 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_has_namespace’:
gio/gfileinfo.c:610:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
610 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_find_value’:
gio/gfileinfo.c:543:9: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
543 | if (i < info->attributes->len &&
| ^
gio/gfileinfo.c: In function ‘g_file_info_clear_status’:
gio/gfileinfo.c:499:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
499 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_set_attribute_mask’:
gio/gfileinfo.c:453:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
453 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_copy_into’:
gio/gfileinfo.c:385:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
385 | for (i = 0; i < dest_info->attributes->len; i++)
| ^
gio/gfileinfo.c: In function ‘g_file_info_finalize’:
gio/gfileinfo.c:327:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
327 | for (i = 0; i < info->attributes->len; i++)
| ^
gio/gdatainputstream.c: In function ‘scan_for_chars’:
gio/gdatainputstream.c:879:40: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
879 | for (i = 0; checked < available && i < peeked; i++)
| ^
gio/gdatainputstream.c: In function ‘scan_for_newline’:
gio/gdatainputstream.c:654:40: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
654 | for (i = 0; checked < available && i < peeked; i++)
| ^
gio/gliststore.c: In function ‘g_list_store_insert’:
gio/gliststore.c:272:30: error: comparison of integer expressions of different signedness: ‘guint’ {aka ‘unsigned int’} and ‘gint’ {aka ‘int’}
272 | g_return_if_fail (position <= g_sequence_get_length (store->items));
| ^~
gio/gliststore.c: In function ‘g_list_store_splice’:
gio/gliststore.c:482:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
482 | for (i = 0; i < n_additions; i++)
| ^
gio/gcancellable.c:773:1: error: missing initializer for field ‘closure_marshal’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’}
773 | };
| ^
In file included from glib/giochannel.h:33,
from glib/glib.h:54,
from gio/gcancellable.c:22:
glib/gmain.h:277:23: note: ‘closure_marshal’ declared here
277 | GSourceDummyMarshal closure_marshal; /* Really is of type GClosureMarshal */
| ^~~~~~~~~~~~~~~
gio/gcontextspecificgroup.c: In function ‘g_context_specific_source_new’:
gio/gcontextspecificgroup.c:77:3: error: missing initializer for field ‘closure_callback’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’}
77 | };
| ^
In file included from glib/giochannel.h:33,
from glib/glib.h:54,
from gobject/gbinding.h:28,
from glib/glib-object.h:22,
from gio/gcontextspecificgroup.h:23,
from gio/gcontextspecificgroup.c:22:
glib/gmain.h:276:19: note: ‘closure_callback’ declared here
276 | GSourceFunc closure_callback;
| ^~~~~~~~~~~~~~~~
gio/inotify/inotify-kernel.c: In function ‘ik_source_new’:
gio/inotify/inotify-kernel.c:377:3: error: missing initializer for field ‘finalize’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’}
377 | };
| ^
In file included from glib/giochannel.h:33,
from glib/glib.h:54,
from gio/inotify/inotify-kernel.c:30:
glib/gmain.h:272:14: note: ‘finalize’ declared here
272 | void (*finalize) (GSource *source); /* Can be NULL */
| ^~~~~~~~
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
The version of `black` on the CI server wanted these changes. Make them
to keep the `style-check-diff` CI job from constantly failing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Try and catch programmer errors in third-party implementations of
`dbus_register()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1188
NULL is valid return value for the g_unix_mount_get_options function
because mount options are currently provided only by libmount implementation.
However, the gio tool passes the returned value to the g_strescape function
without checking, which produces the following critical warning:
GLib-CRITICAL **: 13:47:15.294: g_strescape: assertion 'source != NULL' failed
Let's add the missing check to prevent the critical warnings.
These might help catch the problem in #2119 earlier on, and provide more
information about its root cause.
They should not affect behaviour in normal application usage.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2119
This is technically an API break, as the following assignment may now
raise warnings in user code:
```
gchar *filename = g_osx_app_info_get_filename (app_info);
```
However, from code search it seems like the number of users of that
function is zero.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This command will try to execute a desktop file, before that
it will load the input as a keyfile for checking its existence
and its validity (as a keyfile).
File arguments are allowed after the desktop file.
Closes#54
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Static analysis of the call to `g_dir_new_from_dirp()` is tricky,
because the call is across library boundaries and indirected through a
vfunc map because it’s private to libglib.
Help the static analyser by adding an assertion about the input and
output values for `g_dir_new_from_dirp()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It search for attribute trash::orig-path and move the input file to it.
Possibly recreating the directory of orignal path and/or overwritting
the destination.
Closes#2098
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
There were a couple of places where the return value wasn’t checked, and
hence failure could not be noticed.
Coverity CIDs: #1159435, #1159426
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
From:
9eb9c93275
"we found that the const security_context_t declarations in libselinux
are incorrect; const char * was intended, but const security_context_t
translates to char * const and triggers warnings on passing const char *
from the caller. Easiest fix is to replace them all with const char *."
And later marked deprecated in commit:
7a124ca275
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
This should introduce no API changes. The
`g_dbus_error_register_error_domain()` function still (incorrectly) has
a `volatile` argument, but dropping that qualifier would be an API
break.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
This should introduce no API changes; there are public functions
exported by `GDBusConnection` which still have some (incorrectly)
`volatile` arguments, but dropping those qualifiers would be an API
break.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
And drop the `volatile` qualifier from the variables, as that doesn’t
help with thread safety.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
http://isvolatileusefulwiththreads.in/c/
It’s possible that the variables here are only marked as volatile
because they’re arguments to `g_once_*()`. Those arguments will be
modified in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
These tests were originally written using the output directly from a
fuzzer which had triggered the bugs we’re testing for. However, that
means they’re liable to no longer test what they’re intended to test if
the `GDBusMessage` parsing code is changed to (for example) check for
certain errors earlier in future.
It’s better to only have one invalidity in each binary blob, so change
the test messages to all be valid apart from the specific thing they’re
testing for.
The changes were based on reading the D-Bus specification directly:
https://dbus.freedesktop.org/doc/dbus-specification.html
During these changes I found one problem in
`test_message_parse_deep_header_nesting()` where it wasn’t actually
nesting variants in the header deeply enough to trigger the bug it was
supposed to be testing for. Fixed that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1963
This commit is the unmodified results of running
```
black $(git ls-files '*.py')
```
with black version 19.10b0. See #2046.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Set counters for the number of running tasks and
for the max. threadpool size. These are meant to
get a sense for whether G_TASK_POOL_SIZE and related
constants are still suitable for current gio and
GTask usage patterns.
Previously it was considered a programming error to call these on
subprocesses created without the correct flags, but for bindings this
distinction is difficult to handle automatically.
Returning NULL instead does not cause any inconsistent behaviour and
simplifies the API.
