Rather than having special code in gsocket.c, handle Winsock errors
along with other Win32 errors in gioerror.c
Also, reference g_win32_error_message() from the
g_io_error_from_win32_error() docs, and update the
g_win32_error_message() docs to clarify that it works with Winsock
error codes too.
Map EPROTONOSUPPORT, ESOCKTNOSUPPORT, EPFNOSUPPORT and EAFNOSUPPORT to
G_IO_ERROR_NOT_SUPPORTED in g_io_error_from_errno(). (GSocket's
socket_io_error_from_errno() already did this with the corresponding
Winsock errors.)
Also map EOPNOTSUPP, which on Linux is the same as ENOTSUP, but may
not be on other platforms.
Also, rewrite the EAGAIN/EWOULDBLOCK section to use the simpler idiom
used by EEXIST/ENOTEMPTY and (now) ENOTSUP/EOPNOTSUPP.
Use #GVariant instead of GVariant.
g_notification_add_button_with_target,
g_notification_set_default_action_and_target:
Replace 'format_string' with 'target_format'.
g_notification_set_default_action_and_target_value:
Remove paragraph that apparently had been accidentally copied from
g_notification_set_default_action_and_target.
https://bugzilla.gnome.org/show_bug.cgi?id=727123
In the event that a GSettings object is being destroyed just as a change
signal is being delivered, the destroying thread will race with the
dconf worker thread for acquiring the lock on the GSettingsBackend.
If the signalling thread gets there first then the destroying thread
will block on the lock. The signalling thread adds a reference to the
GSettings object that is being destroyed and releases the lock. The
idea is that this should prevent the GSettings object from being
destroyed and thus maintain its entry in the list. Unfortunately, the
weak reference notify function is already running and as soon as we
release the lock, the list entry is removed.
The signalling thread crashes.
This bug is indicative of a serious problem encountered in many
situations where GObject instances are touched from multiple threads.
Ideally, we will move to a place where g_object_ref() is not called at
all on the GSettings object from the dconf worker thread and instead, a
dispatch will be done without holding a reference (similar to how
GAppInfoMonitor presently works). This would also prevent the
unfortunate case of someone dropping what they assume to be the last
reference on a GSettings object, only to have an already-pending signal
delivered once they return to the mainloop, crashing their program.
Making this change for GSettings (with multiple instances per thread,
the possibility of multiple backends and each instance being interested
in different events) is going to be extremely non-trivial, so it's not a
change that makes sense at this point in the cycle.
For now, we can do a relatively small and isolated tweak so that we
never access the list except under a lock. We still perform the bad
pattern of acquiring a ref in a foreign thread which means that we still
risk delivering a signal to a GSettings object that the user has assumed
is dead (unless they explicitly disconnect their signal handler). This
is a problem that we already had, however.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.
This means that all functions in the table now fit the following signature:
void (* f) (GObject *target,
GSettingsBackend *backend,
const gchar *name_or_path,
gpointer origin_tag,
const gchar * const *names);
allowing the possibility of arguments ignored at the end.
This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.
So far, this should be a straight refactor.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
The _finish functions for GUnixVolume _mount and _eject functions were
never implemented, having been simply stubbed out as 'return TRUE;'.
Implement them.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
The existing code is buggy and now that we have GSubprocess, we should just use
it instead, allowing for some substantial reduction in complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
As of e6af432, g_content_type_get_symbolic_icon() returns non-symbolic
fallbacks. Thus, we can't append another symbolic icon to the fallbacks.
The special case was a bit of a hack anyway. It was only applied to
themed icons and there was no generic fallback for mime types that are
not folders.
https://bugzilla.gnome.org/show_bug.cgi?id=726046
We need to have these in BUILT_SOURCES so that 'make' knows to generate them
before attempting to compile other .c files in the same directory (since some
of these files include the header).
Should fix up remaining issues about partial versions of this file being
included under parallel builds.
https://bugzilla.gnome.org/show_bug.cgi?id=725891
Add a test for GSubprocess to test setting, unsetting and inheritance of
environment variables. Use communicate() to give it a bit more of a
workout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=725651
On the splice for stdout or stderr completing, GSubprocess calls
_slice_finish() to collect the result.
We assume that a zero return value here means failure, but in fact this
function returns a gssize -- the number of bytes transferred, or -1 for
an error.
This causes GSubprocess to mistakenly think that it has an error when it
actually just has an empty buffer (as would be the case when collecting
stderr from a successful command).
Check for -1 instead of FALSE to detect the error.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
Add the basename from the first component of the Exec line to the list of
strings to search for via g_desktop_app_info_search().
We treat Exec as a fairly strong match -- just below the visible name.
Add a testcase to make sure everything is working OK.
https://bugzilla.gnome.org/show_bug.cgi?id=725023
Visual C++ is quite zealous about checking against the types used in the
initializing of array of structures, even up to Visual C++ 2013. Fix this
by splitting up the initializing steps.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
There is no longer any code left in the check/prepare functions on UNIX,
so put %NULL in the GSourceFuncs vtable.
This also allows us to simplify some logic.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
We are reusing the GPollFD.revents field of the source to store a
temporary value. Use a local variable for that instead.
This is a refactor to make the next commit easier to understand.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
Now that GCancellable's GSource is based on _set_ready_time() instead of
an fd, we should use it as a child source, instead of forcing the
creation of the fd and adding it as a poll.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
Windows does not come with inet_aton(), and this check on IPv4 addresses
is actually not needed on Windows as the getaddrinfo() implementation on
Windows already rejects non-standard and non-real IPv4 numbers-and-dots
addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
After getting an EINTR, g_socket_condition_timed_wait() has to adjust
its timeout, but it was trying to convert from nanoseconds to
microseconds by multiplying by 1000 rather than dividing... Oops.
https://bugzilla.gnome.org/show_bug.cgi?id=724239
There is a race condition in the makefile that can result in build failures like this in parallel builds:
| ./gdbus-test-codegen-generated.h:7:0: error: unterminated #ifndef
| #ifndef __GDBUS_TEST_CODEGEN_GENERATED_H__
This is because a rule like this:
x.c x.h: prerequisites
@commands
doesn't consider x.c and x.h together. Instead, it expands to two rules, one to
generate x.c and one to generate x.h, which happen to run the same commands. In
the worst case they execute in parallel, overwriting each other's output.
Signed-off-by: Ross Burton <ross.burton@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723616
If a GSimpleAsyncResult has a NULL source tag, allow it to compare
valid to a non-NULL source tag in g_simple_async_result_is_valid(), to
simplify cases where, eg, g_simple_async_result_new() and
g_simple_async_result_report_error_in_idle() are both used.
https://bugzilla.gnome.org/show_bug.cgi?id=721458
We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
In addition to the standard "192.168.1.1" format, there are numerous
legacy IPv4 address formats (such as "192.168.257",
"0xc0.0xa8.0x01.0x01", "0300.0250.0001.0001", "3232235777", and
"0xc0a80101"). However, none of these forms are ever used any more
except in phishing attempts. GLib wasn't supposed to be accepting
these addresses (neither g_hostname_is_ip_address() nor
g_inet_address_new_from_string() recognizes them), but getaddrinfo()
accepts them, and so the parts of gio that use getaddrinfo()
accidentally did accept those formats.
Fix GNetworkAddress and GResolver to reject these address formats.
https://bugzilla.gnome.org/show_bug.cgi?id=679957
Windows needs a special inefficient hack to implement
g_socket_get_available() correctly for UDP sockets, but that hack
isn't needed for TCP, and in fact, might give the wrong answer in that
case. Fix it to only use the hack with UDP.
Also, fix that case to handle non-blocking sockets as well.
And add a test case for g_socket_get_available() with TCP.
https://bugzilla.gnome.org/show_bug.cgi?id=723422
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Our check for inotify_init1() being defined is broken. We happily
declare that inotify is supported, even if the check fails.
This was originally intended to check for inotify_init1 in the libc so
that we could fall back to inotify_init if it was not yet defined.
FreeBSD has a libinotify that emulates the inotify API via kqueue. It
installs a <sys/inotify.h> header and requires linking to -linotify. We
don't want to falsely detect working inotify in this case.
Treat the lack of inotify_init1() in the libc as a lack of inotify
support. This requires only a new libc -- we still support old kernels:
in the case that inotify1_init() fails, we fall back to inotify_init().
https://bugzilla.gnome.org/show_bug.cgi?id=724330
It’s not enough to close a connection by calling g_input_stream_close()
and g_output_stream_close() on its two substreams: to close the
underlying socket, one must use g_io_stream_close(). Document that.
https://bugzilla.gnome.org/show_bug.cgi?id=724278
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
Add support for parsing command line options with GApplication.
You can add GOptionGroup and GOptionEntry using two new APIs:
g_application_add_option_group() and
g_application_add_main_option_entries().
Also add a "handle-local-options" signal that allows handling of
commandline arguments in the local process without having to override
local_command_line.
As a special feature, you can have a %NULL @arg_data in a GOptionEntry
which will cause the argument to be stored in a GVariantDict. This
dictionary is available for inspection and modification by the
"handle-local-options" signal and can be forwarded to the primary
instance in cases of command line invocation (where it can be fetched
using g_application_command_line_get_options()).
https://bugzilla.gnome.org/show_bug.cgi?id=721977
In some virtualization setups, ifindexes can end up becoming very
large, and so the existing code that assumes that *some* interface
must have an index less than 255 fails.
Fix this by explicitly looking for "lo" first. And then if that fails
(on Windows, or other systems where the loopback interface is not
called "lo"), try indexes up to 1024 rather than 255.
https://bugzilla.gnome.org/show_bug.cgi?id=723048
For some reason, IPv6 link-local multicast routing changes all the
time. GNetworkMonitorBase was already ignoring them for purposes of
emitting network-changed, but GNetworkMonitorNetlink would still
trigger a re-dump after getting one, so network-changed would end up
getting emitted anyway.
glocalfile.c: In function 'g_local_file_measure_size_of_file':
glocalfile.c:2654:3: warning: passing argument 2 of 'g_lstat' from
incompatible pointer type [enabled by default]
if (g_lstat (name->data, &buf) != 0)
^
In file included from glocalfile.c:68:0:
../glib/gstdio.h:135:5: note: expected 'struct GStatBuf *' but argument
is of type 'struct _stati64 *'
https://bugzilla.gnome.org/show_bug.cgi?id=711547
gdbusauthmechanismexternal.c: In function 'mechanism_client_initiate':
gdbusauthmechanismexternal.c:355:3: warning: 'initial_response' may be
used uninitialized in this function [-Wmaybe-uninitialized]
return initial_response;
^
gdbusauthmechanismexternal.c:332:10: note: 'initial_response' was
declared here
https://bugzilla.gnome.org/show_bug.cgi?id=711547
glocalfileinfo.c: In function '_g_local_file_info_get':
glocalfileinfo.c:1955:11: warning: passing argument 3 of
'get_thumbnail_attributes' from incompatible pointer type [enabled by
default]
get_thumbnail_attributes (path, info, &statbuf);
^
glocalfileinfo.c:1285:1: note: expected 'const struct GStatBuf *' but
argument is of type 'struct _stati64 *'
get_thumbnail_attributes (const char *path,
https://bugzilla.gnome.org/show_bug.cgi?id=711547
If the action is stateful and the user doesn't have their own activate handler
then do some reasonable things for ourselves.
After a lot of experience using stateful GSimpleAction it turns out that
people almost always end up using it in the same ways:
A boolean-typed stateful action with no parameter is most likely going
to want to be toggled. Any other type of action that has the parameter
type equal to the state type probably intends for activation to
represent a request to change the state.
This patch implements those two cases. This will let people stop
writing their own trivial handlers over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=722503
Clarify in the documentation that the commandline arguments passed
around by GApplication (to local_command_line and returned via
g_application_command_line_get_arguments()) are in the GLib filename
encoding (ie: UTF-8) on Windows, not the system code page.
Fix the mismatch that would result from having argv passed to
g_application_run() in main() on Windows (where it is in the system
code page) by ignoring argc/argv on Windows and calling
g_win32_get_command_line() for ourselves. Document this.
This might be a slight API break on Windows: we documented that it was
possible to call g_application_run() with arguments other than argc/argv
and now doing that will result in those arguments being ignored. It has
always been recommended practice to only call g_application_run() from
main() directly, however, and all of our code examples have shown only
this. We will see if this causes any issues and consider reevaluating
the situation if so.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add a note to the documentation for g_file_new_for_commandline_arg()
that this function is intended to operate on strings already in the GLib
filename encoding on Windows.
This has been the case for a long time, but this documents the
requirement.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
g_strconcat() allocates memory, it needs to be freed.
==10653== 1,400 bytes in 50 blocks are definitely lost in loss record
1,838 of 1,851
==10653== at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10653== by 0x54ACB22: g_malloc (gmem.c:102)
==10653== by 0x54ACE4D: g_malloc_n (gmem.c:343)
==10653== by 0x54C8463: g_strconcat (gstrfuncs.c:589)
==10653== by 0x4D6ED38: get_xattrs_from_fd (glocalfileinfo.c:660)
==10653== by 0x4D71622:
_g_local_file_info_get_from_fd (glocalfileinfo.c:2028)
==10653== by 0x4D731A0:
g_local_file_input_stream_query_info (glocalfileinputstream.c:356)
==10653== by 0x4C996D8:
g_file_input_stream_query_info (gfileinputstream.c:148)
==10653== by 0x4C863F6: file_copy_fallback (gfile.c:3120)
==10653== by 0x4C86DD2: g_file_copy (gfile.c:3398)
https://bugzilla.gnome.org/show_bug.cgi?id=722357
The default local_command_line handler has a fast return path for the
case that we handle the commandline by forwarding it to the primary
instance, but this doesn't account for the fact that we may want to
become a service.
Allow for this by making sure we don't take the fast path of the service
flag is set.
Add a --gapplication-service switch to the default implementation of
local_command_line. This name is unlikely to clash with any option used
by an existing application.
When a normal application (neither service nor launcher) is launched with
exactly this one argument, G_APPLICATION_IS_SERVICE will be set.
The idea is that people will write their D-Bus service file with
--gapplication-service on the Exec line. This provides a nice
compromise for people who want the benefits of DBusActivatable
applications but without losing the ability to easily run them directly
(under the debugger or inside jhbuild, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=710965
Make sure we escape any special characters that are found in annotation
names or values to avoid emitting a malformed XML document in response
to an Introspect call.
https://bugzilla.gnome.org/show_bug.cgi?id=721796
The file extension of the GIO module could be something other than .so,
depending on platform. Use G_MODULE_SUFFIX so that the test will run
correctly on non-*nix platforms, such as Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
If installed tests are not enabled, installed_testdir is not
defined, so we end up trying to create /modules and to chmod
things in /x-content/, which is not right.
When losing the D-Bus connection, we would write to stdout about it just
before killing ourselves with SIGTERM. We're a library, so we should
probably use stderr instead.
https://bugzilla.gnome.org/show_bug.cgi?id=721324
Part of the purpose of g_settings_get_child() was that it could be used
after you delay() a GSettings object, and then apply() all of the
settings together. In order for that to work, we need to share the
backend.
https://bugzilla.gnome.org/show_bug.cgi?id=720891
The x-content/win32-software type is only recognized if
the autorun.exe file is executable. Since the file is installed
as data, we need to fix up its permissions in an
install-data-hook.
This test is inspired by its namesake in GTK+. We instantiate
all types, and check the default values of their properties,
with some exceptions for types that are known not to work.
In case an object is already monitored, we lock then return without
unlocking it which can then result in a self deadlock. So properly
unlock before returning.
https://bugzilla.gnome.org/show_bug.cgi?id=721074
Use g_variant_parse_error_print_context() to format the error message
from the GVariant parser.
There is a slightly dubious interaction with the "parse me harder"
functionality here. We're probably going to have to deal with that
separately.
https://bugzilla.gnome.org/show_bug.cgi?id=715028
I recently had to track down why these tests failed. Turned
out that some rogue package on my system had installed mime
types that declared all files with 3 letter names to be
'chemical/x-turbomole-vibrational'.
This change will make it more obvious what is going on by
mentioning the mime types in the assertion message.
When replacing a version of goa-daemon (from gnome-online-accounts)
by a newer version with some added interfaces, evolution-data-server
and the gvfs-goa volume monitor might crash as there's no interface
definition for this new interface.
Work-around this by returning earlier from the _notify() implementation,
rather than accessing invalid memory.
https://bugzilla.gnome.org/show_bug.cgi?id=720539
Add missing (allow-none) annotations to
g_desktop_app_info_launch_uris_as_manager(). Tested with
python -c "from gi.repository import GLib, Gio; Gio.DesktopAppInfo.new('gcalctool.desktop').launch_uris_as_manager([], None, GLib.SpawnFlags.SEARCH_PATH|GLib.SpawnFlags.STDOUT_TO_DEV_NULL, None, None, None, None)"
which is necessary to do a launch_uris() without leaking stdout.
https://launchpad.net/bugs/1259721
GDBusConnection cleanup is inherently racy due to its use of worker
threads. Put tests that expect a NULL G_BUS_TYPE_SESSION singleton
as the first tests to work around cleanup races.
https://bugzilla.gnome.org/show_bug.cgi?id=719837
Allow only format strings that copy all values (i.e, don't contain '&'),
as the returned pointers might become invalid in some rare cases.
Since this is technically an API break, this patch only prints a
critical when a faulty format string is detected, but still fetches the
values.
https://bugzilla.gnome.org/show_bug.cgi?id=719979
Usually async methods copy/ref its arguments so caller can
forget about them. g_file_replace_contents_async() and
g_output_stream_write_async() are exceptions.
https://bugzilla.gnome.org/show_bug.cgi?id=690525
The desktop-files directory contains a mimeapps.cache file
that was not installed as data for installed tests, causing
the file measure test to fail only in when installed.
Make the testcase compare the byte size to what is reported
by du. Also add a test for the async api, and mak eit test
the progress reporting callback.
Comparing the code generated for the setter and other methods without
(real) return value, I noticed that the setter does not unref the
gvariant it gets.
https://bugzilla.gnome.org/show_bug.cgi?id=719472
This function turns a varargs argument list into a string array,
but forgets to NULL-terminate it. This function was not covered
by unit tests...so it was broken.
The test reveals that there's something fishy with this monitor.
One has to call g_app_info_get_all() for it to start working,
and then it only works once.
The previous patch to simplify the GSettings commandline tool by making
more use of global variables went a bit too far and broke 'gsettings
monitor' when used without a specific key.
Fix that up again.
The static analyser (correctly) considers a type check to fail if the
variable is NULL. In this case, the address must be non-NULL as no error
was thrown by g_socket_connection_get_remote_address(), but the static
analyser doesn’t know this.
Add a non-NULL assertion anyway, both to shut the analyser up, and
because it’s good extra testing.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
These prevent some false positives from the static analyser which are
caused by it not inspecting the invariants of
g_subprocess_communicate[_utf8]_finish() (i.e. that stdout and
stdout_str will always be set unless an error was returned).
They’re also good testing anyway.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
If the initial part of the header (‘MIME-TreeMagic’) is valid, but the
following line does not start with ‘[’ (i.e. is not a valid section
line), insert_matchlet() will be called with a NULL match pointer, and
will crash with a NULL pointer dereference.
Fix this by bailing out if a valid section line isn’t encountered before
the first insert_matchlet() call (i.e. between the header line and the
first data line).
Note that this has not been tested against a real treemagic file; the
fix is purely theoretical.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
In the case that (n_fds == 0 && fds == NULL), memcpy() would be called
against a NULL src pointer. Even though the number of bytes to copy is
0, avoid the possibility of a crash by only calling if fds is non-NULL.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
The static analyser will check dynamic type assertions and assume that
if they fail, the variable can either have the wrong type, or be NULL
(which is correct). The analyser doesn’t know that other constraints in
the API ensure the variable is non-NULL.
Add a non-null assertion to help the static analyser and shut it up in
this case.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
This can happen if the hash table lookup for ‘noncefile’ fails, and
hence the first ‘goto out’ is hit, at which point resolver is still
NULL.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
Be a little bit more careful in regards to initializing a primitive type
variable before passing it by reference, as it could have random stuff
in the variable's address depending on the CRT, such as MSVCR110.DLL,
causing random, invalid stuff being written in that address.
This will fix this test when built with Visual Studio 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
G_OS #ifdefs are only available once glibconfig.h has been
evaluated ; that is, after including glib headers.
Move this block down so it gets correctly evaluated.
Make it possible to skip the terminal-launching test simply
by setting DISPLAY= . Previously, you had to unset DISPLAY,
which is a little more cumbersome.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
One testcase was launching appinfo-test from a GAppInfo that
does not have a filename. In this case, the G_LAUNCHED_DESKTOP_FILE
envvar is not exported. Make appinfo-test deal with that, without
spewing warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
The actions test tests the GSimpleActionGroup API. Maybe this
should be moved to use GActionMap, but for now, just disable
the deprecations.
There was also one test that wasn't actually hooked up, so
do that as well.
Most _list_schemas() uses were to check for the availability
of a particular schema. g_settings_schema_source_lookup() is
a better way to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=712315
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
My application (hotssh) would like to get the resolved address from DNS,
before we start the connect().
We could add a new event, but it's easy enough to just cache it on the
GSocketConnection; this avoids any new API.
https://bugzilla.gnome.org/show_bug.cgi?id=712547
It makes sense to match on GenericName in case an application does
not provide any keywords, but the Keywords field has been added
to explicitly support the search case, while GenericName was used
to be displayed in menus, so it makes more sense to consider
Keywords more (or equally) relevant for search.
https://bugzilla.gnome.org/show_bug.cgi?id=711640
Just copy the schemas to the builddir and compile them in place instead
of trying to mess around with creating the compiled file in a different
dir. This solves issues in the summary/description testcase when
GSettings expects the usual situation of having the .xml files present
in the same directory.
We need to check for the correct line endings on Windows (\r\n) for the
echo tests and currently need to skip the test_echo_eof test there, as
it depends on the cat utility that is not normally found on Windows, and
using an external installation of cat via MSYS or Cygwin would render the
test program to hang as cat waits for user input.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Various tests were depending on local_error being set by a callback
when it could never have been the case. Simplify async error detection
logic in those cases, and fix leak of GError.
https://bugzilla.gnome.org/show_bug.cgi?id=711802
We had a GApplication testcase that handled both open and commandline.
This only way that this worked was by implementing the commandline
handler without actually setting the HANDLES_COMMAND_LINE flag.
This behaviour is now invalid, so just rip out the offending part of the
test.
https://bugzilla.gnome.org/show_bug.cgi?id=711099
The first time this function is called we load all of the keyfiles in
the directory, ignoring the 'Hidden' ones and build an index out of the
interesting fields using g_str_tokenize_and_fold().
We do prefix matching on the tokens to find relevent desktop files.
Right now this is implemented as a hashtable that we iterate over,
checking prefixes on each token. This could possibly be sped up by
creating an array, but it's already pretty fast...
https://bugzilla.gnome.org/show_bug.cgi?id=711557
