Updated Serbian translation

gbinding: warn on failed value transformation

GBinding warned if g_value_transform() returned FALSE, but it didn't
warn if there was no transformation available at all. Fix that and
test it.

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

update Punjabi Translation 17March2014: Alam

GLib 2.39.92

Updated French translation

GSettingsBackend: fix a nasty race condition

In the event that a GSettings object is being destroyed just as a change
signal is being delivered, the destroying thread will race with the
dconf worker thread for acquiring the lock on the GSettingsBackend.

If the signalling thread gets there first then the destroying thread
will block on the lock.  The signalling thread adds a reference to the
GSettings object that is being destroyed and releases the lock.  The
idea is that this should prevent the GSettings object from being
destroyed and thus maintain its entry in the list.  Unfortunately, the
weak reference notify function is already running and as soon as we
release the lock, the list entry is removed.

The signalling thread crashes.

This bug is indicative of a serious problem encountered in many
situations where GObject instances are touched from multiple threads.
Ideally, we will move to a place where g_object_ref() is not called at
all on the GSettings object from the dconf worker thread and instead, a
dispatch will be done without holding a reference (similar to how
GAppInfoMonitor presently works).  This would also prevent the
unfortunate case of someone dropping what they assume to be the last
reference on a GSettings object, only to have an already-pending signal
delivered once they return to the mainloop, crashing their program.

Making this change for GSettings (with multiple instances per thread,
the possibility of multiple backends and each instance being interested
in different events) is going to be extremely non-trivial, so it's not a
change that makes sense at this point in the cycle.

For now, we can do a relatively small and isolated tweak so that we
never access the list except under a lock.  We still perform the bad
pattern of acquiring a ref in a foreign thread which means that we still
risk delivering a signal to a GSettings object that the user has assumed
is dead (unless they explicitly disconnect their signal handler).  This
is a problem that we already had, however.

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

gsettingsbackend: a minor simplification

Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.

This means that all functions in the table now fit the following signature:

  void (* f) (GObject             *target,
              GSettingsBackend    *backend,
              const gchar         *name_or_path,
              gpointer             origin_tag,
              const gchar * const *names);

allowing the possibility of arguments ignored at the end.

This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.

So far, this should be a straight refactor.

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

Update config.h.win32.in

Make the entries of config.h.win32.in match those that are being checked
in config.h.in.

Updated Portuguese translation

GUnixVolume: implement _finish functions

The _finish functions for GUnixVolume _mount and _eject functions were
never implemented, having been simply stubbed out as 'return TRUE;'.

Implement them.

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

GUnixVolume: port to GSubprocess

Do the same as we just did for GUnixMount, for GUnixVolume too.

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

GUnixMount: port unmount to GSubprocess

The existing code is buggy and now that we have GSubprocess, we should just use
it instead, allowing for some substantial reduction in complexity.

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

Updated Russian translation

glocalfileinfo: don't special-case directory icons

As of e6af432, g_content_type_get_symbolic_icon() returns non-symbolic
fallbacks. Thus, we can't append another symbolic icon to the fallbacks.

The special case was a bit of a hack anyway. It was only applied to
themed icons and there was no generic fallback for mime types that are
not folders.

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

Add g_application_command_line_get_options_dict() to docs

Updated Traditional Chinese translation(Hong Kong and Taiwan)

gtype – Mark _get_instance_private() function as G_GNUC_UNUSED

clang likes to complain about it being unused.

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

Updated Latvian translation

Updated Chinese (China) translation

gio tests: add codegen to BUILT_SOURCES

We need to have these in BUILT_SOURCES so that 'make' knows to generate them
before attempting to compile other .c files in the same directory (since some
of these files include the header).

Should fix up remaining issues about partial versions of this file being
included under parallel builds.

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

GObject: Remove more leftover markup from headers

Updated Korean translation

Updated Norwegian bokmål translation

Unskip GVariantDict

There is no reason to (skip) GVariantDict, it's a boxed type
and perfectly usable from gobject-introspection.

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

cond test: remove alarm() usage

This means that the test can't build on Windows (and we do want it there).

This will be properly resolved with bug 725266, but let's not block the
build before then.

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

Work around gtk-doc problems

Returns shall never be at the beginning of a line.

gsubprocess: test environment a bit more

Add a test for GSubprocess to test setting, unsetting and inheritance of
environment variables.  Use communicate() to give it a bit more of a
workout as well.

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

GSubprocessLauncher: don't get empty environment

Use g_get_environ() to get the environment variables with their values
instead of g_listenv() which only lists off the keys.

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

gsubprocess: test empty splices

Make sure we handle the case that our splice returns no data properly.

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

gsubprocess: fix communicate() with empty buffers

On the splice for stdout or stderr completing, GSubprocess calls
_slice_finish() to collect the result.

We assume that a zero return value here means failure, but in fact this
function returns a gssize -- the number of bytes transferred, or -1 for
an error.

This causes GSubprocess to mistakenly think that it has an error when it
actually just has an empty buffer (as would be the case when collecting
stderr from a successful command).

Check for -1 instead of FALSE to detect the error.

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

GLib 2.39.91

desktopappinfo: add Exec to searchable keys

Add the basename from the first component of the Exec line to the list of
strings to search for via g_desktop_app_info_search().

We treat Exec as a fairly strong match -- just below the visible name.

Add a testcase to make sure everything is working OK.

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

Updated Thai translation

Add a few tests for G_MARKUP_TREAT_CDATA_AS_TEXT

Related to
https://bugzilla.gnome.org/show_bug.cgi?id=725433

Add a way to test different markup parser flags

For now, we are mainly interested in G_MARKUP_TREAT_CDATA_AS_TEXT.
This commit makes markup-parse look for expected output files with
the extension .cdata-as-text in addition to .expected, and compares
the output of parsing with G_MARKUP_TREAT_CDATA_AS_TEXT against
them. markup-parse --cdata-as-text foo.gmarkup can be used to produce
such expected output.

docs: Ditch more markup

Some markup was hiding in docs in headers. Drop it there, too.

Updated Polish translation

hmac: Make unit test const-correct

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

gmain: simplify g_main_context_find_source_by_id()

Since we now keep a hashtable of sources, we can implement this function
without iteration.

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

gmain: Simplify source id tracking

Simplify our tracking of issued source id integers and fix some bugs.

Previously the source's id was remove from the 'used' table from
source_remove_from_context() which was also called if the source
priority was changed (in which case it would never be added back to the
table).  The source id could be reissued in that case.

In the new approach, we just always keep a hash table of sources, by
source id.  This simplifies the logic and will also allow us to improve
performance of g_main_context_find_source_by_id() which is called in some
fairly common cases, such as g_source_remove().  These improvements will be in
the following commits.

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

Test content type icons more thoroughly

Check we actually get the right icon names, and check
that symbolic icons fall back to non-symbolic ones.

Add non-symbolic fallback icons in g_content_type_get_symbolic_icon().

This makes the behavior consistent with e.g. g_volume_get_symbolic_icon().

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

asyncqueue: fix timeout math on 32bit systems

88182d375e13ae6519a288d5295220c83ca27e73 caught this issue in
g_async_queue_timed_pop() but failed to fix the same bug in the _unlocked()
variant.

This is only a problem on 32bit systems.  On 64bit systems, the tv_sec
in a timeval is already 64 bits, so no overflow occurs.

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

mappedfile test: permit ENODEV on /dev/null

mmap() on /dev/null returns ENODEV on old Linux versions and also on
Hurd, so accept that in the testcase.

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

Fix build of gio/gapplication.c on Visual C++

Visual C++ is quite zealous about checking against the types used in the
initializing of array of structures, even up to Visual C++ 2013.  Fix this
by splitting up the initializing steps.

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

gsocket: use check/prepare only on win32

There is no longer any code left in the check/prepare functions on UNIX,
so put %NULL in the GSourceFuncs vtable.

This also allows us to simplify some logic.

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

gsocket: use _add_unix_fd() instead of _add_poll()

Use g_source_add_unix_fd() on UNIX instead of using a GPollFD.

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

gsocket: make use of g_source_set_ready_time()

Drop our own hand-rolled version of the same functionality.

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

GSource: mark some API as "implementation only"

Clarify that _add_poll() _remove_poll() _add_unix_fd(),
_modify_unix_fd(), _remove_unix_fd(), _query_unix_fd(),
_set_ready_time(), _add_child_source() and _remove_child_source() are only
intended to be used by the implementation of a particular GSource -- not its
consumers.

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

gsocket: don't abuse GPollFD.revents field

We are reusing the GPollFD.revents field of the source to store a
temporary value.  Use a local variable for that instead.

This is a refactor to make the next commit easier to understand.

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

gsocket: use cancellable child source

Now that GCancellable's GSource is based on _set_ready_time() instead of
an fd, we should use it as a child source, instead of forcing the
creation of the fd and adding it as a poll.

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

gsocket: trivial typo fix

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

gmain: repeat preconditions for emphasis

g_main_context_acquire() mentions that you must have called it before
you make any calls to _prepare(), _query(), _check() or _dispatch().

For emphasis, add a note on each of those functions pointing back to the
fact that you must have called _acquire() before using them.

g_main_context_wait: add a critical to detect use

Due to its unusual interface, I suspect that nobody is using
g_main_context_wait() but there is no way to know.

Add a critical notice that will be displayed if anyone calls the
function, asking them to file a bug with us.

We'll let this go out with the 2.40 release and see if we get a response
before we proceed with actually breaking the functionality.

GCond: check result of pthread_condattr_setclock()

Make sure this call succeeds, aborting if it doesn't

This will prevent people from having to waste time chasing down the problems
that would otherwise be caused by this silent failure.

gmain: abort if monotonic time is unsupported

We now depend on CLOCK_MONOTONIC, but it's possible that people may
attempt to run GLib on systems where it isn't supported at runtime.

Check the return value of clock_gettime() and abort() if it fails in
order to save these people from wasting time on debugging a tricky
issue.

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

GHashTable: Explicitly document that _iter_remove() is safe while iterating

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

Updated Lithuanian translation

glib/Makefile.am: Dist gtranslit-data.h

This header needs to be distributed as well, which was
inadvertently missed.

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

slow-motion post-release version bump

gconvert: add note to avoid transliteration

Add a note to the documentation of g_convert() advising to avoid using
it for transliteration.  Link to g_str_to_ascii().

gsource: document priority of child sources

Add a note to the documentation that child sources cannot have their priority
changed independently from their parent.  Add a g_return_if_fail() to the
public API in order to enforce this.

This was already a reality due to the check in
g_source_set_priority_unlocked(), but it was never explicitly documented.

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

g_str_to_ascii(): a couple of minor tweaks

Add a precondition guard and use g_string_sized_new() to avoid some
reallocations.

g_str_tokenize_and_fold: do proper transliteration

g_str_tokenize_and_fold() can now do proper locale-sensitive
transliteration for ascii alternatives.

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

tests: test transliteration API

Add some tests for the new transliteration API.

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

Add locale-sensitive ASCII transliteration API

Add a new function, g_str_to_ascii() that does locale-dependent ASCII
transliteration of UTF-8 strings.

This function works off of an internal database.  We get the data out of
the localedata shipped with glibc, which seems to be just about the best
source of locale-sensitive transliteration information available
anywhere.

We include a update script with this commit that's not used by anything
at all -- it will just sit in git.  It is intended to be run manually
from time to time.

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

tests: add a test for g_cond_wait_until()

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

Fix g_cond_wait_until() vs. monotonic time

We've had a relatively rocky path with g_cond_wait_until() on systems
that either don't support pthread_condattr_setclock() or where
g_get_monotonic_time() is not based on CLOCK_MONOTONIC (ie: Android and
Mac OS).

Fortunately, both of these platforms seem to share
pthread_cond_timedwait_relative_np() which allows us to implement
g_cond_wait_until() without races.

With this patch, we now require that one of pthread_condattr_setclock()
or pthread_cond_timedwait_relative_np() exists.  A quick look around
suggests that this is true for all platforms that we care about.

This patch removes our use of pthread_cond_timedwait_monotonic() and
pthread_cond_timedwait_monotonic_np() which were Android-only APIs.

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

gmain: rework g_get_monotonic_time() a bit

We now assume the existence of clock_gettime() and CLOCK_MONOTONIC as
specified by POSIX.1-2001.  This means that we always return truly
monotonic time, which will prevent problems in the case that the user
changes the time.

Mac OS doesn't have clock_gettime() but it does have
mach_absolute_time(), so we can use that there.

We keep our Windows case as well (although we should simplify it once XP
hits EOL later this year).

This patch removes the fallback to gettimeofday() in case of missing
clock_gettime().  We no longer have any way to test this codepath and
therefore it must go.

This patch also restructures the #ifdef a bit so that we repeat the
entire function definition inside of #ifdef instead of just the entire
body of one function.

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

docs: use "Returns:" consistently

Instead of "Return value:".

gio/gresolver.c: Fix build on Windows

Windows does not come with inet_aton(), and this check on IPv4 addresses
is actually not needed on Windows as the getaddrinfo() implementation on
Windows already rejects non-standard and non-real IPv4 numbers-and-dots
addresses.

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

Updated Norwegian bokmål translation

Add G_ÂTYPE_VARIANT_DCT into the doc

GLib 2.39.90

Work around test failure in gdbus-names

This is caused by g_test_dbus_down() returning too soon.

Add a sleep for now.

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

GApplication: disable some more tests

Disable some racy GApplication testcases.  We need some better non-hacky
GApplication tests...

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

Bump gtk-doc dep to 1.20

gsocket: fix g_socket_condition_timed_wait() recovery after EINTR

After getting an EINTR, g_socket_condition_timed_wait() has to adjust
its timeout, but it was trying to convert from nanoseconds to
microseconds by multiplying by 1000 rather than dividing... Oops.

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

gtestutils: make the new assert messages more detailed

g_assert_true(), g_assert_false(), g_assert_null(), and
g_assert_nonnull() simply printed out the expression they were
checking, without any further explanation of what went wrong. (In
particular, "g_assert_true(x)" and "g_assert_false(x)" would both
print the same thing on failure.) Add a little bit more context.

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

gio/tests: fix race when generating code

There is a race condition in the makefile that can result in build failures like this in parallel builds:

| ./gdbus-test-codegen-generated.h:7:0: error: unterminated #ifndef
|  #ifndef __GDBUS_TEST_CODEGEN_GENERATED_H__

This is because a rule like this:

x.c x.h: prerequisites
@commands

doesn't consider x.c and x.h together. Instead, it expands to two rules, one to
generate x.c and one to generate x.h, which happen to run the same commands.  In
the worst case they execute in parallel, overwriting each other's output.

Signed-off-by: Ross Burton <ross.burton@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723616

subprocess: Init and clear the mutex

Fixes the leak of the GMutexImpl allocated inside the first call to g_mutex_lock()
on an uninitialized GMutex.

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

Annotate g_application_add_main_option_entries

g_simple_async_result_is_valid: fix for NULL source tag

If a GSimpleAsyncResult has a NULL source tag, allow it to compare
valid to a non-NULL source tag in g_simple_async_result_is_valid(), to
simplify cases where, eg, g_simple_async_result_new() and
g_simple_async_result_report_error_in_idle() are both used.

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

Fix the build on FreeBSD by replacing EAI_NODATA with EAI_NONAME.

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

win32: fixup lib.exe invocation

We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries.  That has been broken
for a long time for two reasons:

 1) the Makefiles hardcode 'lib' instead of 'lib.exe'

 2) we dropped generation of .def files quite some time ago (except for
    in gthread where we have the two-symbol file under version control)

Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.

Add a bit of $(AM_V_GEN) all around, as well.

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

only '#pragma GCC' outside of functions

Don't use #pragma GCC inside of function scope.

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

gio: don't accept nonstandard IPv4 "numbers-and-dots" addresses

In addition to the standard "192.168.1.1" format, there are numerous
legacy IPv4 address formats (such as "192.168.257",
"0xc0.0xa8.0x01.0x01", "0300.0250.0001.0001", "3232235777", and
"0xc0a80101"). However, none of these forms are ever used any more
except in phishing attempts. GLib wasn't supposed to be accepting
these addresses (neither g_hostname_is_ip_address() nor
g_inet_address_new_from_string() recognizes them), but getaddrinfo()
accepts them, and so the parts of gio that use getaddrinfo()
accidentally did accept those formats.

Fix GNetworkAddress and GResolver to reject these address formats.

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

gobject: re-allow finalization from constructor()

Although returning NULL from constructor is strongly discouraged, some
old libraries need to keep doing it for ABI-compatibility reasons.
Given this, it's rude to forbid finalization from within
constructor(), since it would otherwise work correctly now anyway (and
the critical when returning NULL should discourage any new uses of
returning NULL from constructor()).

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

Fix g_socket_get_available() with TCP on Windows

Windows needs a special inefficient hack to implement
g_socket_get_available() correctly for UDP sockets, but that hack
isn't needed for TCP, and in fact, might give the wrong answer in that
case. Fix it to only use the hack with UDP.

Also, fix that case to handle non-blocking sockets as well.

And add a test case for g_socket_get_available() with TCP.

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

docs: Remove a few trailing <literal>s

docs: Remove some unneeded decorations

@var is not expanded inside literal `` blocks.
Just remove those @ characters.

docs: let go of &ast;

Since we are no longer using sgml mode, using /&ast; &ast;/ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //

configure.ac: tweak inotify check

Our check for inotify_init1() being defined is broken.  We happily
declare that inotify is supported, even if the check fails.

This was originally intended to check for inotify_init1 in the libc so
that we could fall back to inotify_init if it was not yet defined.

FreeBSD has a libinotify that emulates the inotify API via kqueue.  It
installs a <sys/inotify.h> header and requires linking to -linotify.  We
don't want to falsely detect working inotify in this case.

Treat the lack of inotify_init1() in the libc as a lack of inotify
support.  This requires only a new libc -- we still support old kernels:
in the case that inotify1_init() fails, we fall back to inotify_init().

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

gtask: fix trivial doc typo

g_test_run: return 0 if all tests are skipped in TAP mode

Exit status 77 is special to Automake's default test driver, but is
treated as an error by TAP.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724124
Reviewed-by: Dan Winship <danw>

glib/tests/collate.c: run to completion when skipping all tests

Otherwise, we don't produce valid TAP output, and fail with:

    ERROR: collate - missing test plan

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724124
Reviewed-by: Dan Winship <danw>

gsocketconnection: Document closing connections with g_io_stream_close()

It’s not enough to close a connection by calling g_input_stream_close()
and g_output_stream_close() on its two substreams: to close the
underlying socket, one must use g_io_stream_close(). Document that.

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

gsocketservice: Clarify g_socket_service_stop() documentation

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

g_child_watch_source_new: POSIX pid must be positive

If we used a non-positive pid, we'd call waitpid(that_pid, ...)
which is exactly the situation this function can't deal with.

On Windows, GPid is a HANDLE (pointer), so I don't think the same thing
applies.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723743
Reviewed-by: Ryan Lortie

Be more clear that g_return_if_fail is undefined behaviour

In particular, it is not incorrect to g_return_if_fail (..., FALSE)
in a function returning a "success" gboolean and a GError: "failure to
meet the preconditions is an error" takes precedence over the
GError documentation's guarantee that the error will be set on failure.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=660809
Reviewed-by: Emmanuele Bassi