It turns out that this bug actually would (sometimes) impact any sort of
fixed-sized array with an alignment requirement of 8 due to incorrectly
counting the alignment inserted between the (aligned 4) array length and
the actual data.
Fix this properly and remove the exception for doubles.
https://bugzilla.gnome.org/show_bug.cgi?id=732754
We're using a precondition in the middle of the function, and if we
hit it, we leak the closure.
Let's allocate the closure per path; this allows us to allocate it
before path-specific preconditions, and better avoids a pointless
malloc/free pair in the unhandled case.
https://bugzilla.gnome.org/show_bug.cgi?id=733576
This reverts commit 7269d75321.
Adding G_STATIC_ASSERT() into a header file caused compilation
problems with at least one app (Anjuta). Reverting to keep
GNOME continuous testing running.
https://bugzilla.gnome.org/show_bug.cgi?id=730932
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
