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
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
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
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
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
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
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
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
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
We are a bit too aggressive about freeing memory in strv mode. Only
free it in the case that we actually set the pointer to NULL.
Uncovered by the GApplication tests.
Slightly expand on the documentation about casting varargs when
constructing GVariants, and link to it from all the functions where it’s
a necessary consideration.
Add an example of passing flags to a ‘t’ type variable (guint64).
Assuming the flags enum does not have many members, the flag variable
will be 32 bits wide, and needs an explicit cast to be passed into
g_variant_new() as a 64-bit value.
https://bugzilla.gnome.org/show_bug.cgi?id=712837
