To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
... otherwise we might end up using the worker after it has been
freed. Reported by Dan Winship and Colin Walters.
This fix uncovered a bug in the /gdbus/nonce-tcp test case so "fix"
that as well to use a better way of having one thread wait for another
(using quotes for the word "fix" since it's pretty hackish to
busy-wait in one thread to wait for another).
Signed-off-by: David Zeuthen <davidz@redhat.com>
-Seperate intermediate directories for each project to avoid intermittent
MSBuild errors that a build log cannot be written while in use, and
update the property sheet as necessary.
-Minor cleanups of uneeded tags in the projects/properties
These tools require the use of GModule headers also, so update the include
directories so that the correct gmodule.h will be included instead of the
system-installed version.
These will validate the resulting line, and throw a conversion error.
In practice these will likely be used by bindings, but it's good
for even C apps too that don't want to explode if that text file
they're reading into Pango actually has invalid UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
g_data_input_stream_read_line() and
g_data_input_stream_read_line_finish() don't do any encoding checks,
so we shouldn't call the returned value a "string" (which I'd like to
mean UTF-8). Annotate them as byte arrays and add encoding warnings
to the docstrings.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
There is no chance that an unsigned integer value will be negative after
we do the bounds check that enforces its non-negativity.
Caught by Matthias running Coverity.
Running gthread/tests/spawn-multithreaded in a loop, I very easily hit:
GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
Testing the refcount still left a window where we would fall into the
assertion. Fix this by just locking the context.
We should by default reset signal handlers; particularly with the
ability to install them via g_unix_signal_source_new(), we don't
want to call a user callback inside a fork()ed helper process.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
I was debugging gthread/tests/spawn-multithreaded.c, and while I
don't think I actually hit EINTR in any of these cases, it'd be
good to fix them anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
