Fix the GLib Visual Studio Projects

Define the G_LOG_DOMAIN of the GLib DLL as "GLib", because:
-This makes it consistent with the autotools builds
-Some tests expect the log domain to be "GLib"

Update config.h.win32(.in)

Make the entries of config.h.win32(.in) consistent with the entries
that are generated from the autotools build (config.h.in).

Avoid a segfault in gdbus tool

When the interface name is invalid, we don't get an error
back from g_dbus_connection_call_sync.

build: Fix usage of %.test again

We actually need the first dependency because it includes the
final executable name.  Rather, fix the original bug by using
the variable $(EXEEXT).

tests: Drop unnecessary % from .test pattern match rule

On Windows, the executables will have .exe, so this won't
match.  Furthermore, they aren't actually dependent on the
executable to build.

Updated Spanish translation

Assamese translation updated

Updated Gujarati Translations

G_GNUC_FORMAT: documentation error

Attribute should be placed just before the semicolon, not after.
As can be seen in the example.

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

spelling fixes of 'runtine' and 'adresses' in cross.xml and running.xml, respectively

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

gsignal: remove some pointless locking

We previously hold a lock in the loop that collects the arguments for
g_signal_emit(), which we drop before calling into the argument
collection functions and reacquire again at the bottom of the loop (ie:
one release/acquire pair for each argument collected).  To make matters
worse, the lock is just released again after the loop.

Presumably that was done to protect the access to the parameter array,
but it's pretty unlikely that this is needed because the only way it
changes is if the signal is unloaded.  That only happens when unloading
types which is quite unlikely to happen while we are emitting on an
instance of that type (and, as an aside, never happens anymore anyway).

If we move the unlock below the loop up above it and remove the
acquire/release pair from the loop, we improve performance in the new
arg-collecting performance tests by ~15% (more like ~18% in the case
where we only emit to one handler -- where argument collection dominates
more).

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

performance test: add signal test with args

Add a signal that has some typical arguments (a uint and a pointer)
since all of the other signal performance tests are for signals with no
args.

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

performance test: share some code

The handled and unhandled cases share the same data and _run()
functions.  Refactor into a common section.

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

gunixconnection: added ngettext to support plural forms

While those strings ("Expecting 1 control message, got %d" and
"Expecting one fd, but got %d\n") have same singular/plural form
in english, it is not necessarily the case in other languages.

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

GLocalFileOutputStream: Further deduplicate error code path

Just code cleanup.

https://bugzilla.gnome.org/699959

GLocalFileOutputStream: Deduplicate stream creation code

Lots of copy/paste of the error handling path, let's deduplicate
so I can sanely patch this code later.

https://bugzilla.gnome.org/699959

gdbus-peer: Drop some usage of g_thread_yield()

It's a recipe for race conditions and error; on some hardware
architectures one thread isn't guaranteed to see the results
of writes from another thread without a cache flush.

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

glib/tests/cond: Fix race condition

The producer could push two values with the first one being
lost.  Fix this by blocking the producer until a consumer
reads.

gtestutils: Use stdio rather than write() to be Windows-friendly

Windows doesn't define STDOUT_FILENO and STDERR_FILENO, and they're
not even guaranteed to be 1 and 2. So just use stdio instead. Also fix
a counting error. Pointed out on gtk-devel-list.

Timeout the test if dbus sevice has not appeared in due time.

The test /gdbus/connection/large_message waits for a dbus name to appear.
The dbus name is created by a another process executed in the background.
If for some reason this fails, the test will likely wait forever.
This will avoid this situation by making the test fail if the dbus service
has not appeared after 10 seconds.

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

po: update for quote changes

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

Use 'dumb quotes' rather than `really dumb quotes'

Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.

However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.

Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.

Fix this by just using 'dumb quotes' everywhere.

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

tests: fix a few recently-broken tests

gio/tests: Fix gdbus-connection when run from "make check"

Convert more tests to installed tests

This makes the tests in tests installed, except for
the performance tests.

Convert more tests to installed tests

gio/tests: gsettings is a developer-only test

It tries to run glib-compile-schemas and glib-mkenums, which
we won't have in the runtime tree.

Anyways it's kind of a dumb test since the best test for
compilation tools is...compiling things, which we already
do frequently.

gmessages: Fix up testing commit to handle fatal masquerading

This makes glib/tests/testing pass again.

gio/tests: Disable desktop-app-info test in installed mode for now

It wants a writable copy of the applications, and appears to
depend on a prior execution of "mimeapps".  This will take
a bit of work to untangle.

gio/tests: Make gdbus-peer work in installed mode

There's no /etc/hosts in gnome-ostree...

gio/tests: Fix gapplication test in installed mode

gio/tests: Some more fixes for installed tests

file passes now, appinfo needs a bit more work, but is getting
there.

gio/tests: Deduplicate Makefile.am a bit

We can just add all the static test data to EXTRA_DIST.

gtestutils: Ensure test subprocesses don't dump core

Since we expect them to crash, let's not spam the system
core dump collection (systemd, abrt).  At the moment
systemd is not very robust against programs crashing
in loops.

Instead of aborting, we exit(1).

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

Updated Norwegian bokmål translation

Convert remaining gio tests to installed

Convert some gio tests to installed tests

Make gobject tests installable

This makes the gobject tests run as part of the ostree integration
tests.

[l10n] Updated Italian translation.

Add --enable-installed-tests configure option

See https://live.gnome.org/GnomeGoals/InstalledTests for more
information.

The tests now support being run both uninstalled and installed, so
'make check' works for those who want it.  For tests which need data
files, the way this works is they look in the compiled in value of
SRCDIR by default, and the generated tests use "env G_TEST_DATA=" to
override that.

This patch only converts glib/tests for now; if this patch looks good,
I'll do the rest of the tests.

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

glib/tests: Drop unnecessary SRCDIR definitions

It's always going to be defined, we don't support compiling these
tests "by hand".  This is a cleanup commit for the installed tests
work.

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

glib/tests: Use explicit file listings

This is a preparatory commit for installed tests work; having things
cleanly categorized helps.

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

glib/tests/mappedfile: Copy test file before writing to it

This way we're *always* testing writability rather than only sometimes
doing it in the source directory.

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

Added Aragonese translation

m4macros/glib-gettext.m4: Don't use AC_HEADER_STDC

AC_HEADER_STDC is obsolete (pre-C89 headers are no longer an issue),
and the resulting STDC_HEADERS define is anyway not used.

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

updated kn translations

tests/slice: use G_GNUC_BEGIN_IGNORE_DEPRECATIONS

rather than implementing it by hand

gtestutils: use g_clear_pointer

gtestutils: deprecate g_test_trap_fork()

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

tests: port from g_test_trap_subprocess() to g_test_trap_fork()

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

tests/protocol: redo a bit

Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).

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

gtestutils: add g_test_trap_subprocess()

g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.

Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.

Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.

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

g_test_trap_fork: don't blow away the SIGCHLD handler

Not sure why it was doing this, but it's not necessary (all of glib's
tests pass fine without it), and it breaks tests that try to use
g_spawn_sync() or GChildWatchSource after doing a g_test_trap_fork().

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

tests/spawn-*.c: fix on Windows

Need to append ".exe" to the spawned binary name on Windows

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

app: Document when floating variants are consumed

Bug #700203.

Updated Odia Translation.

Clarify GValueArray docs

Don't refer to Quicksort in the documentation of
g_value_array_sort, but just to qsort().

Updated Telugu Translations

Fix minor typos in GSocketConnectable example code

Declare res_init() for builds against Android's Bionic

res_init() exists in the C library here and as such is detected
by configure, but it is not declared in any header.

GProxyAddressEnumerator: add default-port property

Although none of the in-tree GSocketConnectable types need it, other
types (like SoupAddress) may find it useful to be able to pass a URI
and a default-port to GProxyAddressEnumerator separately (the same way
you can with GNetworkAddress). So add a default-port property.

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

Document all gtester-report options

The --subunit option was missing from the man page.

Document all glib-mkenums placeholders

The @ENUMPREFIX@ placeholder was missing in the man page.

Document all glib-genmarshal options

The --stdinc option was missing from the man page.

Fix a typo

Document all gdbus-codegen options

The --help and --xml-files options were missing from the man page.

gbitlock: fix this to not unconditionally use futex emulation

Ryan accidentally committed some debugging code a long time ago,
causing this file to always use futex emulation even when real futex
support was available. I noticed this a while later and pointed it out
to him, and assumed he was going to fix it, but I guess he assumed I
was going to fix it, and then neither of us did...

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

Silently handle icon being NULL

While an emblemed icon without a base icon is not very
useful, no need to crash here.
This was crashing the object finalization test in gtk.

binding: Add an explicit unbind()

Higher order languages with garbage collection can have issues releasing
a binding, as they do not control the last reference being dropped on
the binding, source, or target instances.

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

tests/mappedfile: Also handle ENOMEM

The RHEL6.4 kernel gives me that instead of EINVAL.

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

gobject: rename an unused parameter to make AIX happy

GSocks5Proxy: don't crash if parsing negotiation reply fails

The GError should be initialized to NULL, otherwise we'll
"pile up" errors, then try to free an uninitialized pointer.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=699493

hindi update

Updated Slovenian translation

Bump version to 2.37.1

Add 2.38 indexes to the docs

Updates

gio: fix small leak

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

GApplication: don't leak 'hint' on remote Open

We were using format string "s" to deconstruct the open hint into a
'const gchar *' which, of course, we never freed.  Fix that.

bytesicon: don't use g_object_unref() on GBytes

We need to use g_bytes_unref()

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

bytesicon: fix a memory leak

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

configure: Assume C90 compatible malloc() prototype

This ancient code was attempting to cope with (unknown) systems whose
malloc() prototype was incompatible with the standard.  This test was
fragile; it would break if the build environment provided -Wall in
CFLAGS.

Now that it's 2013, let's assume that target systems have a sane
malloc().  If someone complains, we can revisit this.

https://bugzilla.gnome.org/698716

g_object_new: check for NULL from _constructor()

There is some code in the wild (like in gnome-session) that does this
from its custom _constructor() implementation:

{
  GObject *obj;

  obj = ((chain up));

  if (!object_is_viable (obj))
    {
      g_object_unref (obj);
      return NULL;
    }
  else
    return obj;
}

This has never been a valid use of GObject and this code has always
caused memory to be leaked[1] by growing the construction_objects list.
The ability to legitimately return NULL from a constructor was exactly
the reason that we created GInitable, in fact.

That doesn't change the fact that the g_object_new() rewrite will crash
in this case, so instead of doing that, let's emit a critical and avoid
the crash.  This will allow people to upgrade their GLib without also
upgrading their gnome-session.  Meanwhile, people can fix their broken
code.

[1] not in the strictest sense of the word, because it's still reachable

Tamil Translation Updated

gio/tests: Find "true" in PATH opposed to hardcoding the location

Not all systems have /usr/bin/true. Some have it in /bin/true.
Instead of trying to guess a hardcoded path to find it, let
g_app_info_create_from_commandline() internally search PATH
to find the program.

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

[l10n] Updated Italian translation.

docs: fix docs for g_icon_[de]serialize()

Updated Polish translation

GObject: substantially rework g_object_new()

Make a number of improvements to g_object_new():

 - instead of looking up the GParamSpec for the named property once in
   g_object_new() (in order to collect) and then again in g_object_newv
   (when actually setting the property), g_object_new_internal() is a
   new function that takes the GParamSpec on the interface to avoid the
   second lookup

 - in the case that ->constructor() is not set, we need not waste time
   creating an array of GObjectConstructParam to pass in.  Just directly
   iterate the list of parameters, calling set_property() on each.

 - instead of playing with linked lists to keep track of the construct
   properties, realise that the number of construct properties that we
   will set is exactly equal to the length of the construct_properties
   list on GObjectClass and the only thing that may change is where the
   value comes from (in the case that it was passed in)

   This assumption was already implicit in the existing code and can be
   seen from the sizing of the array used to hold the construct
   properties, but it wasn't taken advantage of to make things simpler.

 - instead of allocating and filling a separate array of the
   non-construct properties just re-iterate the passed-in list and set
   all properties that were not marked G_PARAM_CONSTRUCT (since the ones
   that were construct params were already used during construction)

 - use the new g_param_spec_get_default_value() API instead of
   allocating and setting the GValue for each construct property that
   wasn't passed from the user

Because we are now iterating the linked list of properties in-order we
need to append to that list during class initialising instead of
prepending.

These changes show a very small improvement on the simple-construction
performance testcase (probably just noise) and they improve the
complex-construction case by ~30%.

Thanks to Alex Larsson for reviews and fixes.

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

GParamSpec: add g_param_spec_get_default_value()

The way of getting the default value out of a GParamSpec is to allocate
a GValue, initialise it, then call g_param_spec_set_default() to set the
default value into that GValue.

This is exactly how we handle setting the default value for all of the
construct properties that were not explicitly passed to g_object_new().

Instead of doing the alloc/init/store on all construct properties on
every call to g_object_new(), we can cache those GValues in the private
data of the GParamSpec itself and reuse them.

This patch does not actually make that change to g_object_new() yet, but
it adds the API to GParamSpec so that a future patch to GObject can make
the change.

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

GType: add accessor for instance private offset

Since instance private data is now always at a constant offset to the
instance pointer, we can add an accessor for it that doesn't also
require an instance.

The idea is that classes can call this from their class_init and store
it in a file-scoped static variable and use that to find their private
data on instances very quickly, without a priv pointer.

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

Partially revert "Merge waitpid() from g_spawn_sync into gmain()"

This partially reverts commit ce0022933c255313e010b27f977f4ae02aad1e7e.

It used to be safe to use g_spawn_sync() from processes that had their
own SIGCHLD handler because it simply called wait().  When it was
changed to depend on the GLib child watching infrastructure this meant
that GLib had to own the SIGCHLD handler.

This caused hangs in at least Pidgin.

The patch contained two other improvements to the child watch code which
we want to keep, so only revert the changes to gspawn itself.

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

Test GUnixSocketAddress construction

This test fails without the previous fix and works properly with it.

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

GUnixSocketAddress: fix construct parameter issue

GUnixSocketAddress has some very strange logic for interpreting its
construct paramters.  This logic behaves differently in these two cases:

  g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
                "abstract", FALSE,
                "address-type", ...,
                NULL);

and

  g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
                "address-type", ...,
                NULL);

even though the default value for "abstract" is already FALSE.

Change the way the code works so that it is not sensitive to people
merely setting a property to its default value.

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

gtype: tweak valgrind hints

The valgrind client requests were not producing the intended result in
some cases, so step up our game a bit.

Revert "GObject: prevent installing properties after init"

This reverts commit ddb0ce14215cd62c7a2497d6cf9f2ea63c40ebb5.

Colin's smoke testing has found issues in at least gjs and
gnome-settings-daemon.  We'll need to see if we can address those.

GObject: prevent installing properties after init

GObject has previously allowed installing properties after class_init
has finished running.  This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.

Prevent this from happening.  Require that all properties are installed by
the time class_init has finished.

Complaints go to this bug:

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

gtype: put private data before the instance

Classically, a GTypeInstance has had the following layout:

 [[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]

where TypeB is a subclass of TypeA which is a GObject.  Both TypeA and
TypeB use pivate data.

The main problem with this approach is that the offset between a pointer
to an instance of TypeA and the TypeAPrivate is not constant: it changes
depending on the depth of derivation and the size of the instance
structures of the derived types.  For example, changing the size of the
TypeB structure in the above example would push the TypeAPrivate further
along.

This complicates the implementation of g_type_instance_get_private().
In particular, during object construction when the class pointer to the
'complete type' of the object is not yet stored in the header of the
GTypeInstance, we need a lookup table in order to be able to implement
g_type_instance_get_private() accurately.

We can avoid this problem by storing the private data before the
structures, in reverse order, like so:

  [TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]

Now the distance between TypeA and TypeAPrivate depends only on the size
of GObject and GTypeInstance, which are static.  Even in the case of
TypeB, the distance is not statically known but can be determined at
runtime and is constant (because we will know the size of TypeAPrivate
by the time we initialise TypeB and it won't change).

This approach requires a slighty dirty trick: allocating extra memory
_before_ the pointer we return from g_type_create_instance().  The main
problem with this is that it will cause valgrind to behave very badly,
reporting almost everything as "possibly lost".

We can correct for this by including a few valgrind client requests in
order to inform it that the start of the GTypeInstance should be
considered a block of memory and that pointers to it should mean that
this block is reachable.  In order to make the private data reachable,
we also declare it as a block and include an extra pointer from the end
of the primary block pointing back at it.  All of this is only done if
we are running under Valgrind.

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

gslice: disable by default under valgrind

All experienced GLib hackers know that G_SLICE=always-malloc is
absolutely essential when valgrinding but many users of GLib don't know
about this and get hit pretty hard when valgrinding their programs.

When initialising gslice, add a check to see if we are running under
valgrind and disable ourselves if we are.

We only do the check in the case that G_SLICE= was not specified in the
environment, so setting it to an empty string will prevent this default
behaviour.

I considered modifying gslice to use the VALGRIND_MALLOCLIKE_BLOCK
client request in all cases in order to just mark the blocks properly
but these calls are not free and gslice is pretty hyper-optimised.  It's
easier to just disable gslice completely and this way we only have to do
one check during startup.  It's also theoretically possible that someone
might want to use valgrind to debug gslice, in which case the extra
annotations would probably cause quite a lot of difficulty.

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

Add a copy of valgrind.h to glib/

This is a BSD-licenced header file that is designed to be copy-pasted
into programs.  It will allow us to detect if we are running under
Valgrind and send "client requests" to it.

We will use this for a couple of reasons in upcoming patches.

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