This code assumes that int is exactly 4 bytes, and that pointers
are either 4 or 8 bytes, on platforms with __ATOMIC_SEQ_CST.
In practice this is going to be true.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
This is a best-effort approach to preventing SIGPIPE emissions on Darwin
and iOS, where they continue to be intercepted by the Xcode debugger
even if SIG_IGN prevents them crashing the program.
This is similar to the existing code which sets MSG_NOSIGNAL on all
send() calls. MSG_NOSIGNAL doesn't exist on Darwin though.
Based on a patch from Philip Withnall.
https://bugzilla.gnome.org/show_bug.cgi?id=728730
Since we are getting passed Unicode values these global vars
might not have the correct value. Instead always get the wide arguments
and convert them to utf8 to use them.
https://bugzilla.gnome.org/show_bug.cgi?id=733146
When establishing a D-Bus connection failed, g_dbus_object_manager_client_finalize()
calls g_object_ref(manager->priv->connection) when that pointer is NULL,
which is considered and logged as error by glib.
https://bugzilla.gnome.org/show_bug.cgi?id=732984
Detect the following two errors:
- attempting to unlock a mutex that is not locked
- attempting to clear a mutex that was not initialised or was
initialised but is still locked
Both of these are fatal errors. We avoid using g_error() here because
doing so would involve calls back into the GMutex code, and if things
are going off the rails then we want to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
If we have futex(2) then we can implement GMutex natively and gain a
substantial performance increase (vs. using pthreads).
This also avoids the need to allocate an extra structure in memory when
using GMutex or GCond: we can use the structure directly.
The main reason for the increase in performance is that our
implementation can be made more simple: we don't need to support the
array of options on pthread_mutex_t (which includes the possibility, for
example, of being recursive).
The result is a ~30% improvement in uncontended cases and a much larger
increase (3 to 4 times) in contended cases for a simple testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
When GLib had been told to expect message X, but then actually saw
message Y, it would log the "did not see expected message" error with
message Y's log level and domain, which makes no sense. Change it to
log with domain "GLib" and G_LOG_LEVEL_CRITICAL instead.
Also, include the expected domain in the error message, so that if
that's the reason why the expectation didn't match, you can tell that
from the error message.
Update glib/tests/testing.c for these changes; for all other test
programs in GLib and elsewhere, this change should not break any
existing tests, it should only improve the output on failure.
https://bugzilla.gnome.org/show_bug.cgi?id=727974
We don't use this for anything inside of GApplication yet, but Gtk is
about to start using it to find various bits of the application (such as
its menus, icons, etc.).
By default, we form the base path from the application ID to end up with
the familiar /org/example/app style.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
This is not a functional change, as the hints field is static and hence
automatically initialised to zero — which happens to be what AF_UNSPEC
and the unspecified protocol are defined as. However, it’s best to be
explicit about this, in case AF_UNSPEC is _not_ defined as zero.
https://bugzilla.gnome.org/show_bug.cgi?id=732739
I recently needed to nul-terminate the returned buffer, and I wasn't
sure if g_input_stream_read() does that or not. I've checked
glocalfileinputstream.c, which calls read(2) which doesn't nul-terminate
the buffer. So I assume it's the same behavior for all GInputStream
subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=732704
When using this API, I wasn't sure what the cancellable does. I think
it's generally desirable to kill the subprocess if the wait operation is
cancelled, since in this case the application is no longer interested by
the subprocess.
https://bugzilla.gnome.org/show_bug.cgi?id=732704
Be a bit more careful when copying and updating the property sheets, so that
we don't accidently change fields with '10' in them that are actually not
indicating the Visual Studio version.
...so that builds of GLib on x64 Visual C++ can be restored, as the build
fails in line 449 of valgrind.h as it only supports MinGW/GCC for x64
Windows and simply will not build otherwise. Make the x64 Visual C++
builds compile again by defining NVALGRIND when GLib is being built for
Windows on x64 Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=732465
A critical message is printed when a parameter of g_file_equal() is not
a GFile. When we read the documentation before this commit, we can think
that passing NULL or another type than GFile is allowed, but it is not
the case.
Another option is to allow NULL parameters. But for consistency with
e.g. g_str_equal(), it's probably better to keep the code as is.
https://bugzilla.gnome.org/show_bug.cgi?id=732357
