Most variables were, but a few were not declared as local, and hence
leaked into the calling environment every time someone tab-completed the
`gio` command.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2275
- When querying a TCP socket, getsockopt() may succeed but the resulting
`optlen` will be zero. This means we'd previously be reading
uninitialized stack memory in such cases.
- After a file-descriptor has gone through FD-passing, getsockopt() may
fail with EINVAL. At least this is the case with TCP sockets.
- While at it also use SOL_LOCAL instead of hard-coding its value.
When loading a GKeyFile, the sequence is usually:
keyfile = g_key_file_new();
g_key_file_load_xxx(keyfile, ...)
g_key_file_new() calls g_key_file_init(), which allocates a parse_buffer
for parsing. g_key_file_load_xxx() will then g_key_file_clear() the
keyfile and call g_key_file_init() again.
Just don't allocate a parse_buffer unless we need it for parsing.
If no pointer to a GError* has been passed to public API, there's not
need to look at translations via gettext or format an error message that
g_set_error_literal will entirely ignore in the end.
Contrary to what the WSARecvFrom seem to imply, a UDP socket is perfectly recoverable and usable after a WSAECONNRESET error (and, I assume, WSAENETRESET).
However GSocket condition has the FD_READ bit set after a UDP socket fails with WSAECONNRESET, even if no data is available on the socket anymore; this causes select calls to report the socket as readable when, in fact, it's not.
The change resets FD_READ flag on a socket upon the above error conditions; there's no 'if' to filter between datagram and stream sockets as the change should be harmless in the case of stream sockets which are, however, very unlikely to be usable after a WSAECONNRESET.
Factor out the GError creation to a common function. When adding a
support for extended error types, this will limit the number of places
where these errors are allocated.
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).
