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
