GStaticMutex: ABI fixup

Everything was OK as long as GMutex was backed by pthread_mutex_t on
POSIX.  Since this is no longer the case, the ABI of GStaticMutex was
broken.

Fix that up by using pthread_mutex_t directly in the structure.  Since
that's potentially incompatible with our GMutex implementation, set
g_thread_use_default_impl to FALSE to cause the fallback code (which
manually allocates a GMutex) to run, even in the case of
already-existing code (without the need for a recompile).  This will
cause the pthread_mutex_t part of the struct to be completely ignored.

Compile private test with -pthread on UNIX

We are using explicit pthread calls here, so we should
use the right linker flags for that.

https://bugzilla.gnome.org/show_bug.cgi?id=661318

Don't use deprecated GThread API in gio tests

Updated Norwegian bokmål translation

Updated Lithuanian translation

Silence deprecation warnings in deprecated/

We know we are all deprecated here...

Add G_GNUC_DEPRECATED to deprecated functions in gio

Add G_GNUC_DEPRECATED to deprecated functions in gobject

Add G_GNUC_DEPRECATED to deprecated APIs in glib

Add some GHookList tests

Test a few more GIOChannel functions

Remove a bit of dead code

Pass G_DEBUG=g-gc-friendly when running the tests

Add some more GMarkup tests

Call setlocale in markup-parse test

This is necessary to make utf-8 text come out properly.

Improve GNode test coverage

Improve GCache test coverage

Improve coverage of string function tests

Improve coverage of GHmac tests

Add a test for g_date_time_new_from_timeval_utc

gio: enable test_peer regression test for OpenBSD

https://bugzilla.gnome.org/show_bug.cgi?id=661255

GDBusConnection: Make pending calls error when the connection is lost

If the connection to the bus is lost while a method call is ongoing,
the method call does not get cancelled. Instead it just sits around
until it times out.

This is visible here on XO laptops when stopping the display manager
during shutdown. imsettings starts sending a sync message to give up
its bus name (via g_bus_unown_name()), then systemd terminates the
session bus at approximately the same time. imsettings then hangs for
about 20 seconds before timing out the message.

 http://lists.freedesktop.org/archives/dbus/2011-September/014717.html

imsettings behaviour could be improved as described in that thread,
but I think this is a glib bug. I've also come up with the attached
patch which fixes it.

Credits for the bug-fix goes to Daniel Drake <dsd@laptop.org>. The test
case was written by David Zeuthen <zeuthen@gmail.com>.

https://bugzilla.gnome.org/show_bug.cgi?id=660637

Signed-off-by: David Zeuthen <davidz@redhat.com>

Bug 661129: Duplicate symbols zero_thread and g_once_mutex on OSX

Add g_main_context_ref_thread_default()

Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.

https://bugzilla.gnome.org/show_bug.cgi?id=660994

Updated Spanish translation

USE __COUNTER__ instead of __LINE__ when available

I've seen builds fail with

nm-connection.c:119:691: error: declaration of '_GStaticAssertCompileTimeAssertion_119' shadows a previous local [-Werror=shadow]

because several compile-time assertions ended up on the same
line. __COUNTER__ is meant specifically for the purpose of
constructing identifiers, so use it when available.

Don't redundantly redeclare

It makes gcc throw an error:

redundant redeclaration of 'g_static_mutex_get_mutex_impl' [-Werror=redundant-decls]

Move G_LOCK below GMutex in the docs

The flow is currently a bit wrong since G_LOCK makes reference to GMutex
which was not yet defined, so switch things around.

.gitignore

Several docs cleanups

Cleanup thread documentation

gobjet/gclosure.c: Fix styling issues

...so that it looks more consistent with the rest.

gobject/gclosure.c: Add type cast for int_val = value

This will silence compiler warnings on Visual C++.

(Sorry for the bad fix just now.)

Revert "gobject/gclosure.c: Made up for missed pointer deref"

This reverts commit d792a1ebe445cfab942ee9e079daa3b87bd60304.

gobject/gclosure.c: Made up for missed pointer deref

The value parameter is a gpointer * (void **), but ffi_arg itself is not a
pointer type, so make up for dereference here.

gthread-deprecated.c: Include gutils.h

This is needed for declaration of inline.

config.h.win32(.in): Update for strcasecmp

Visual C++ uses _stricmp, which is identical to strcasecmp on gcc.

Update threads docs for the demise of g_thread_init()

Remove mention of gthread-2.0.pc from 'Compiling' section

At the same time, add one or two other corrections.

Add a warning to g_thread_init_with_errorcheck_mutexes

Should anybody try to use this, we should at least tell them that
its gone.

closure: fix handling of ENUMs and integral return types on 64-bit BE platforms

enums are stored in v_long but need to be marshalled as signed
integers.  On platforms where int is 32 bits, taking the
address of v_long resulted in the wrong 32 bits being marshalled.
So we need to stuff the enum's int-sized value to a temporary
int-sized variable and marshall that instead.

Second, on return, libffi actually returns a pointer to a value
that's sized according to platform conventions, not according to
what the caller requested.  ie if ffi_type_sint was requested, the
value can still be a 64-bit sign-extended long on a 64-bit
architecture like PPC64, thus the caller cannot simply cast
the return value as a pointer to the desired type, but must cast
as a pointer to an integral type and then cast to the desired
type to remove any sign extension complications.

For more information on how to correctly handle libffi return
values, see the following bug, specifically comment 35:

https://bugzilla.redhat.com/show_bug.cgi?id=736489

"For 64-bit ABIs that extend integral returns types to 64-bits, libffi always
returns full 64-bit values that you can truncate in the calling code.   It's
just the way it is has always been.  Please don't change libffi.  I'll document
this clearly for the next version (perhaps there is a mention of this, I
haven't looked yet).

The same is true for returning 8-bit values, for instance, on 32-bit systems.
All ABIs extend those results to the full 32-bits so you need to provide a
properly aligned buffer that's big enough to hold the result."

https://bugzilla.gnome.org/show_bug.cgi?id=659881

gmacros: Hide G_STATIC_ASSERT from g-ir-scanner

The C syntax here is twisted and confuses the scanner.  We don't
need to see it, so let's just skip it.

https://bugzilla.gnome.org/show_bug.cgi?id=660413

Be sure to #include "gutils.h" in gbacktrace.c

0e3f530185d494dbb9db1b47f72f10f3ae598564 introduced a compiler warning
about implicit declaration of g_get_prgname().  Fix that.

Problem caught and fix suggested by Rico Tzschichholz.

GDBus: Regenerate code when the codegen or options passed to it changes

https://bugzilla.gnome.org/show_bug.cgi?id=660498

Signed-off-by: David Zeuthen <davidz@redhat.com>

Fix up some doc comments that referred to threads not being enabled

(and a few other unrelated comment fixes)

GDBus: disable two more GDBus tests using fork()

Signed-off-by: David Zeuthen <davidz@redhat.com>

GDBusProxy: Correctly handle unknown members when having an expected interface

Since it is valid for a D-Bus interface / service to add new methods,
signals or properties we must NEVER warn about unknown properties or
drop unknown signals or disallow unknown method invocations when we
have an expected interface.

So this means that the expected_interface machinery is only useful for
checking that the service didn't break ABI.

Also update the docs so it is clear exactly what it means to have an
expected interface.

https://bugzilla.gnome.org/show_bug.cgi?id=660886

Signed-off-by: David Zeuthen <davidz@redhat.com>

gthreadedresolver: remove a bit of cruft

Remove a test that only made sense when GThreadedResolver was the base
class for the two non-threaded resolver classes that no longer exist.

Remove cruft from g_strerror and g_strsignal

We can just assume that strerror/strsignal are available
nowadays. At the same time, drop use of thread-private storage.
Instead, always return interned strings.

https://bugzilla.gnome.org/show_bug.cgi?id=660849

Misc test coverage improvements

https://bugzilla.gnome.org/show_bug.cgi?id=660849

Need to check for prlimit

Add a test for thread creation failure

gthread.h: a bunch of pointless whitespace changes

Make it look pretty.

Move typedef GStaticPrivate to deprecated/

This was missed in the earlier move.

Deprecate g_{mutex,cond}_{new,free}()

Now that we have _init() and _clear(), these old calls are no longer
useful.

https://bugzilla.gnome.org/show_bug.cgi?id=660739

gdbusprivate: fix a missed g_mutex_free()

This should have been changed to g_mutex_clear()

Remove g_mutex_new()/g_cond_new() in testcases

These were the last users of the dynamic allocation API.

Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).

https://bugzilla.gnome.org/show_bug.cgi?id=660739

drop errorcheck mutex test

We don't support errorchecking mutexes in GLib anymore.

GVariant: add a clarification to the docs

Add a note to the doc for g_viarnat_get_child_value() that the return
value is non-floating and must be freed with g_variant_unref().

https://bugzilla.gnome.org/show_bug.cgi?id=654412

gtimer: remove warnings about threads

GTimer no longer uses the thread system for time information and
g_thread_init() no longer does anything, so remove the doubly-untrue
warning about these topics.

https://bugzilla.gnome.org/show_bug.cgi?id=527214

end the glib-ctor experiment

This was a bad approach.  We attempt to handle initailisation in a more
centralised way now.

Test that g_slice_set_config() works

For a while it didn't work, due to the ctor-based initialisation of
gslice.

https://bugzilla.gnome.org/show_bug.cgi?id=660887

gslice: stop using ctors

We can't initialise gslice from a ctor because g_slice_set_config() must
be called before gslice initialisation.

Instead, do the initialisation in a threadsafe way from the
initialisation function for the thread private data.  This will only be
called once per thread so the synchronisation doesn't pose a significant
overhead here.

Ensure that we try to grab the thread private data directly on entrance
to g_slice_alloc() so that we force the initialisation to occur.
Grabbing the private data is the common case anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=660887

win32: stop leaking GPrivate data

Instead of running the GPrivate destructors from our thread proxy code,
run it from the DllMain handler for the DLL_THREAD_DETACH case.

This should ensure that thread-local data is free at the exit of all
threads -- not just the ones we created for ourselves.

https://bugzilla.gnome.org/show_bug.cgi?id=660745

Add GPrivate destroy notify testcase

Ensure that GPrivate destroy notifies are properly called.

This test currently fails on win32 (where we are leaking).

https://bugzilla.gnome.org/show_bug.cgi?id=660745

win32 fixes from g_thread_init() deprecation

I can't even begin to imagine how these fell through the cracks...

gitignore

Deprecate g_thread_init()

Move the last few things that needed thread-safe initialisation to a
global ctor.

https://bugzilla.gnome.org/show_bug.cgi?id=660744

Clean up process of calling g_debug_init()

Make sure that it calls absolutely nothing that may ever recurse back
into GLib again:

  - g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at
    the top.  As far as I know, the only ASCII character letter that
    would get special treatment here is "i" and that appears in neither
    "help" nor "all".

  - g_getenv() is very complicated on Windows, so use a simple version
    that is sufficient for our purposes.

Now that it's completely safe, we can just call it from g_logv() in the
usual way without all of the hacks.

https://bugzilla.gnome.org/show_bug.cgi?id=660744

Add _g_io_module_get_default(), use to simplify other *_get_default()s

Add _g_io_module_get_default(), which implements the
figure-out-the-best-available-module-that-is-actually-usable logic,
and use that to simplify g_proxy_resolver_get_default(),
g_settings_backend_get_default(), g_tls_backend_get_default(), and
g_vfs_get_default().

https://bugzilla.gnome.org/show_bug.cgi?id=620932

gsettingsbackend: remove useless check

GMemorySettingsBackend is always present, so there's no need to check
for "no backends available"

https://bugzilla.gnome.org/show_bug.cgi?id=620932

gio/tests/socket-client: fix a crash (and some indentation)

Bug 660851: Update GIO for changes in GThread API

gsocket.c: Use intern string instead of GStaticPrivate/
           g_static_private_set, as Dan suggested.

[gio] Improve doc for g_file_make_directory_with_parents()

g_file_make_directory_with_parents() will fail for already
existing directories, unlike g_mkdir_with_parents(), so mention
this clearly in the docs.

https://bugzilla.gnome.org/show_bug.cgi?id=660791

Fix an invalid non-looping use of GCond

The GIOScheduler was using a GCond in a way that didn't deal with the
possibility of spurious wakeups.  Add an explicit predicate and a loop.

Problem caught by Matthias Clasen.

https://bugzilla.gnome.org/show_bug.cgi?id=660739

GIO: switch a couple more GMutex users to _init()

Move a couple more GIO users off of _new()/_free() to _init()/_clear().

https://bugzilla.gnome.org/show_bug.cgi?id=660739

Make G_ASSERT_STATIC work with clang

A simplified variant of an approach proposed by Behdad.

https://bugzilla.gnome.org/show_bug.cgi?id=660413

GDBus codegen: generate code with embedded GMutex

Modify GDBus code generator to emit code that uses GMutex embedded into
the structure of the skeleton instead of a pointer.

https://bugzilla.gnome.org/show_bug.cgi?id=660739

GThreadedResolver: port to embedded GMutex/GCond

This is the only case that was non trivial to port, due to some of the
logic being based on checking the GCond* for being non-%NULL.

https://bugzilla.gnome.org/show_bug.cgi?id=660739

GMain, ThreadPool: embed GCond in struct

Use an embedded GCond and g_cond_init()/clear() instead of a pointer
with g_cond_new() and _free().

https://bugzilla.gnome.org/show_bug.cgi?id=660739

GCancellable: use GCond and GMutex directly

Use a statically-allocated GCond and directly use GMutex instead of
making use of the undocumented G_LOCK_NAME() macro.

https://bugzilla.gnome.org/show_bug.cgi?id=660739

GDBus: switch to struct-embedded GMutex and GCond

Now that we have those, we should use them.

https://bugzilla.gnome.org/show_bug.cgi?id=660739

gstringchunk.c: Include gutils.h

This is due to usage of the inline keyword which may not be universally
defined unless guils.h is included.

Add README notes about recent changes

macro wrappers for g_once_init_enter/leave

Give the macro wrapper treatment to g_once_init_enter() and leave() in
the same style that we did for gatomic.

It is now possible to use these macros with any pointer-sized object,
and not just gsize.  The leave() macro ensures that the initialisation
result is a compatible type with the pointer that it is being written
to.

Just like with gatomic, there could be problems caused by use of (void*)
casts.  We'll see how that goes, and reevaluate if necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=660743

Fix DATADIRNAME on OpenBSD.

On OpenBSD translation files are always installed under PREFIX/share/locale,
there is no such thing as PREFIX/lib/locale; according to that, set
DATADIRNAME to "share".

rec-mutex testcase: add a performance test

Add a reasonable performance test for uncontended and contended cases at
different levels of recursion depth.

In the GVariant intro, mention lack of built-in endianness, and rationale

Presumably, the rationale for not storing the endianness is that
GVariant is a recursive type system, and in a sane format, endianness
only needs to be stored once per blob of data (once per D-Bus message,
once per file on disk, etc.).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

g_variant_get_data: mention what you need to know to deserialise

Also include a shorter version in the docs for g_variant_store, with a
pointer to g_variant_get_data.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

g_variant_new_from_data: mention that the caller might need to byteswap

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

Fix a typo in describing GVariant serialisation functions

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

Escape percent sign in g_variant_new_parsed documentation

Strings matching /%[a-z]/ are special syntax for gtk-doc.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

g_variant_get_fixed_array: document which types are appropriate

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

GVariant docs: be clear that the serialisation format isn't the same as D-Bus

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>

Be clear that g_str_hash etc. don't accept NULL

This covers the str, double, int, int64 hash and equal functions, but not
anything that takes an "object", since the convention is that "object
methods" never accept NULL anyway.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>

Be completely clear about what g_direct_hash, g_direct_equal do

Also annotate them as (allow-none), more for the benefit of gtk-doc
readers than introspection.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>

GHashTable: be more clear what g_int_hash wants

Using g_int_hash, g_int_equal with keys like GINT_TO_POINTER (n) seems to
be a reasonably common GLib-novice mistake. It doesn't help that the
documentation for GHashFunc was ambiguous about this.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>

Warn when classes/instances exceed the allowed size, if possible

It's impossible to check this if the library user is using
g_type_register_static, but in that case their compiler should hopefully
warn about the truncation. This fixes it for G_DEFINE_TYPE and friends,
at least.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=659916
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>

Update glibconfig.h.win32(.in)

Update typedef of GStaticMutex here to match the typedef of GMutex
in glib/gthread.h (due to commit c5634df6)

Improve test coverage in the thread tests

Use g_thread_new_full() in some places.