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.

Improve test coverage in the GString tests

Improve testcoverage in the rec-mutex test

Test g_rec_mutex_trylock() in both locked and unlocked cases.

Add a few more tests

This brings test coverage for glist.c and glist.c to the
coveted 100% lines mark.

Remove bits of dead code identified by coverage tests

These lines could were not hit by our tests, and examination
of the code reveals that they can't ever be hit.

Add some more thread tests

GAsyncQueue: properly set free function

The copying of code from g_async_queue_new() to g_async_queue_new_full()
in ef08aa786bca87c520ef319b97df4b3ed0782233 copied the setting of the
free function to NULL (instead of the one passed in by the user).

Fix that up so that the test passes again.

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

GUnixMountPoint: expose options

Make the options from an /etc/fstab entry available as public API -
this can be used to support options such as

 comment=gvfs.name=Foo\040Bar

to e.g. set the name of an fstab mount in the UI to "Foo Bar".

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

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

Revert "GSettings: don't abort on missing schemas"

This reverts commit c841c2ce3fda6f754c88ae2c9099f36dff2f0814.

This approach has been an unmitigated disaster.  We're getting all sorts
of crashes due to functions that are returning NULL because they can't
find the schema for the default value.  The people who get these crashes
are then confused about the root cause of the problem and waste a lot of
time trying to figure it out.

Until we find a better solution, we should go back to what we had
before.

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

Cosmetics

Documentation fixes

Fix doc build

The markup here was not only broken, it was also unnecessary,
since gtk-doc knows to apply <function></function> tags to things
that end with () already.

locks: Add initialisation notes

For each of the 4, mention that static storage or _init() is needed.

locks: change the ABI just a bit

Add a little bit more room in the ABI for our synchronisation primatives
since we're going to need it when we add native implementations on
Linux.

Also: rename the pointer field and add /*< private >*/ annotations.

locks: drop _INIT macros

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

Re-enable 'include' testcase

The bug is fixed now.

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

GThread posix: switch to Windows ABI

Modify the POSIX implementation of the synchronisation primatives to use
the same ABI as Windows: one pointer for each type.

This frees us from having to #include <pthread.h> and avoids the problem
with pthread_rwlock_t not being defined under certain compiler defines.

A few more changes are expected to the ABI -- they will be committed
separately.

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

Don't use g_thread_foreach in tests

Deprecate GStaticPrivate and g_thread_foreach

This commit moves GStaticPrivate, g_thread_foreach and all
related functions and variables to gthread-deprecated.c. We
introduce some internal API to make this possible.

g_thread_foreach is not a very useful function, since there is
virtually nothing you can do with a GThread*, and implementing
it requires us to keep a list of threads around.

GStaticPrivate has been made redundant by adding comparable
capabilities to GPrivate.

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

Don't put threads created with g_thread_new() on the list

This lets us avoid the overhead of maintaining the global
list in the non-deprecated case.

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

Make thread names useful in a debugger

Associate the name with the system thread, so that debuggers
can see it. This is currently only implemented for Linux, using
prctl.

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

Add new thread creation API

Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.

Change GThreadPool, GMainContext and GDBus to create named threads.

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

Define GLIB_COMPILATION when building libgthread.so

This is necessary, because gthreadprivate.h can only be
included inside GLib, otherwise single-include guards trigger.

Replace static privates by privates

GStaticPrivate is heading for deprecation soon, and GPrivate
can replace these uses now.

win32: fix GPrivate fallout

Fix minor mistake in win32 GPrivate code.

locks: rename a bunch of parameters

Stop dithering over GPrivate

Take out the half-private g_private_init() stuff and replace it with a
G_PRIVATE_INIT macro that allows specifying a GDestroyNotify.

Expose the GPrivate structure in a public header.

Add a g_private_replace() to (sort of) match the functionality of
g_static_mutex_set().

Improve the documentation.

Deprecate g_private_new().

Add a few comments

Add another GCond test

This test shows how to implement a barrier using a GCond.

Rework the way GStaticPrivate data is freed

To avoid iterating threads in g_static_private_free(), defer freeing
the per-thread data to thread exit. The one complication here is
that it is possible for the static private index to be reused while
'old' data is still around. To deal with that case, store the 'owner'
with each per-thread data node, and free old data in
g_static_private_get() if the owner doesn't match. The remaining
possibility that a private index could be reused by a GStaticPrivate
with the same address is sufficiently unlikely that we can probably
ignore it.

With this change, per-thread data is now truly private again,
and we can drop the lock for it as well.

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

Whitespace fixes

Clean up includes