All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
Replace it with g_thread_create_with_stack_size() and a real function
implementation of g_thread_create().
Modify a testcase that was calling g_thread_create_full()
inappropriately (it was using the default values anyway).
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
At the same time, also add g_mkdtemp_full and g_dir_make_tmp
variants. The patch also unifies the unique-name-generating
code for all variants of mkstemp and mkdtemp and adds tests
for the new functions.
Based on patches by Paolo Bonzini,
http://bugzilla.gnome.org/show_bug.cgi?id=118563
If we are going to fail an assert, wait for a bit longer before doing so
(up to 5 seconds, if needed).
This is a long-standing Debian patch to fix build failures on really
slow machines.
g_thread_init() causes a hash table to be allocated (in read_aliases).
Since hash tables are now a bit larger, we need to bump one of the
probe sizes to avoid our probe slice being used for the aliases
hash table.
Of course, a proper implementation of close() will just ignore an
invalid parameter silently, and set errno. But apparently the "debug"
version of the Microsoft C library generates some noise in this
case. So avoid that. Thanks to John Emmas for reporting.
