For the GPtrArray example, several variables declared on the same line
is harder to read and to work with (to move, remove or comment a single
variable declaration).
As an example, the core of gedit is in a private library
placed in %INSTALLDIR%/lib/gedit/libgedit.dll
Before this patch we would get %INSTALLDIR%/lib/gedit as the
installation package dir, while what we actually want is to get
%INSTALLDIR%
https://bugzilla.gnome.org/show_bug.cgi?id=733934
Practically no caller of these functions require atomic behaviour,
but the atomics are much slower than normal operations, which makes
it desirable to get rid of them. We have not done this before because
that would be a break of the ABI.
However, I recently looked into this and it seems that even if the
atomics *are* used for g_clear_* it is not ever safe to use this. The
atomics protects two threads that are racing to free a global/shared
object from freeing the object twice. However, any *user* of the global
object have no protection from the object being freed while in use,
because there is no paired operation the reads and refs the object
as an atomic unit (nor can such an operation be implemented using
purely atomic ops).
So, since nothing could safely have used the atomic aspects of these
functions I consider it acceptable to just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=733969
This reverts commit 7269d75321b9d2a967a59fb35f243397f577eb41.
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
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
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
...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
- g_subprocess_launcher_spawn() and spawnv(): there is no other way
AFAIK to create a GSubprocess from a launcher. So these
functions are not "convenience helper".
- annotate optional arguments for g_shell_parse_argv().
- other trivial fix
https://bugzilla.gnome.org/show_bug.cgi?id=732357
Our internal call to g_io_channel_read_line_backend() may return
G_IO_STATUS_ERROR, in which case two things will be true:
- the GError will have been set (if appropriate)
- the &got_length return value may not have been set
Since it's our convention to leave 'out' parameters untouched in
exception cases, this is perfectly fine. Unfortunately,
g_io_channel_read_line(), in wrapping this internal function, always
promotes the length parameter, even in the case of error.
Stop doing that in order to avoid overwriting the callers's variable
with junk in the error case.
https://bugzilla.gnome.org/show_bug.cgi?id=731339
Move width table generation into the gen-unicode-tables.pl script. This makes
updating the tables automatic without the previously required manual editing
required to insert the tables in the right place of the source code.
memcmp() is declared by glibc as follows:
/* Compare N bytes of S1 and S2. */
extern int memcmp (const void *__s1, const void *__s2, size_t __n)
__THROW __attribute_pure__ __nonnull ((1, 2));
despite the fact that it is valid to call it with a null pointer if the
size is zero.
gcc 4.9.0 contains a new optimisation that sees that we pass a pointer
to this function and concludes that it certainly must not be null,
removing a later check and thereby causing a crash.
We protect the invocation of memcmp() with a condition to prevent gcc
from making this false assumption (arguably under wrong advice from
glibc).
The code in g_wakeup_signal() is currently correct: it writes a 64-bit
counter increment value if the FD is an eventfd, and writes an arbitrary
8-bit value if using a normal pipe.
However, the reasoning behind these buffer sizes is not clear, and the
mismatch between the allocated buffer size and the length passed to
write() in the pipe case could be mistaken for a bug.
Coverity issue: #1159490https://bugzilla.gnome.org/show_bug.cgi?id=732002
clang defines the macro that we use to test for GCC's extension support
for C11 atomics, but doesn't define the extension in the same way.
Check for clang and disable the macros again if we find it.
https://bugzilla.gnome.org/show_bug.cgi?id=731513
A static analyzer flagged the g_file_get_contents() call as not
checking its return value. While the code here is actually correct,
it's verbose at best.
I think the "goto out + cleanup" code style is substantially cleaner,
less error prone, and easier to read. It also will pacify the static
analyzer.
https://bugzilla.gnome.org/show_bug.cgi?id=731584
Give compiler a hint that these should be inlined,
which doesn't seem to happen by default with -O2.
Yields 5% speedup in artificial benchmarks, and
1% speedup in a real-world test case doing a lot
of mutex locking and unlocking.
https://bugzilla.gnome.org/show_bug.cgi?id=730807
GCC does not yet support ISO C11 atomic operations, but it has
compatible versions available as an extension. Use these for load and
store if they are available in order to avoid emitting a hard fence
instruction (since in many cases, we do not need it -- on x86, for
example).
For now we use the fully seqentially-consistent memory model, since
these APIs are documented rather explicitly: "This call acts as a full
compiler and hardware memory barrier".
In the future we can consider introducing new APIs for the more relaxed
memory models, if they are available (or fall back to stricter ones
otherwise).
https://bugzilla.gnome.org/show_bug.cgi?id=730807
