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
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().
Replace it with g_thread_create_with_stack_size() and a real function
implementation of g_thread_create().
Modify a testcase that was calling g_thread_create_full()
inappropriately (it was using the default values anyway).
Create a deprecated/ directory that we can start moving ancient chunks
of code to. Start with GAllocator, GMemChunk and related APIs.
Also drop all mention of them from the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659427
Previously, we were returning an empty buffer for all filenames
where fstat() gives a size of 0. But this is only appropriate
for regular files.
Also improve the documentation around this issue. Based on a
patch by Ryan Lortie.
Conflicts:
glib/tests/mappedfile.c
https://bugzilla.gnome.org/show_bug.cgi?id=659212
The boolean values to be returned by a GSourceFunc are always ambiguous,
and even in case of experienced developers then can lead to confusion.
The Perl bindings for GLib have two simple constants, mapping to TRUE
and FALSE, that make the return values less confusing: G_SOURCE_CONTINUE
and G_SOURCE_REMOVE respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=631413
Commit ab0e9dbfa76e056f875e969c0d7b6e133ec75431 introduced some changes
to the documentation Makefiles designed to clean-up the process of
deciding which headers get scanned for the docs.
Unfortunately, the gtk-doc Makefile doesn't use HFILE_GLOB for actually
generating the docs -- only for knowing when it needs to redo the
generation. Because of this, we need to use IGNORE_HFILES or otherwise
we get hundreds of symbols in the *-unused.txt files.
Revert the changes that that commit made to the docs Makefiles (but
leave the generation of the *-public-headers.txt files in place).
Change the unix signal watch API to match other sources in both
available functions, names of those functions and order of the
parameters to the _full function.
https://bugzilla.gnome.org/show_bug.cgi?id=657705
Several different codebases in GNOME want to implement wall clocks.
While we could pretty easily share a private library, it's not a
substantial amount of code, and GLib already has a lot of the
necessary system-specific detection and handling infrastructure.
Note this initial implementation just wakes up once a second in the
cancel_on_set case; we'll add the Linux-specific handling in a
subsequent commit.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
The main rationale for adding it was to avoid having gnome-shell
mmap'ing /etc/localtime once a second. However, we can just as easily
run inotify there, and given no one else was clamoring for a way to
detect when the time zone changes, I don't see a need for public API
here - at least not yet.
In the bigger picture, I just don't believe that the vast majority of
applications are going to go out of their way to instantiate and keep
around a random GTimeZoneMonitor class. And if they do, it's has the
side effect that for other bits of code in the process, local GDateTime
instances may start varying again!
So, if code can't rely on local GDateTime instances being in a
consistent state anyways, let's just do that always. The
documentation now says that this is the case. Applications have
always been able to work in a consistent local time zone by
instantiating a zone and then using it for GDateTime constructors.
We fix the "gnome-shell stats /etc/localtime once a second" issue by
using timerfd (in glib) and inotify (in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=655129
At the same time, also add g_mkdtemp_full and g_dir_make_tmp
variants. The patch also unifies the unique-name-generating
code for all variants of mkstemp and mkdtemp and adds tests
for the new functions.
Based on patches by Paolo Bonzini,
http://bugzilla.gnome.org/show_bug.cgi?id=118563
This implements g_hmac_xxx() functionality using the standard checksum
functions supported by glib.
HMAC is a secure way to hash a key and a password. Many other
approaches fraught with append and prepend issues.
Includes test cases defined in relevant RFCs
https://bugzilla.gnome.org/show_bug.cgi?id=652480
This commit changes GLib size units policy. We now prefer SI units and
allow for use of proper IEC units where desired.
g_format_size_for_display() which incorrectly mixed IEC units with SI
suffixes is left unmodified, but has been deprecated.
g_format_size() has been introduced which uses SI units and suffixes.
g_format_size_full() has also been added which takes a flags argument to
allow for use of IEC units (with correct suffixes). It also allows for
a "long format" output which includes the total number of bytes. For
example: "238.5 MB (238,472,938 bytes)".
Add G_VARIANT_TYPE_OBJECT_PATH_ARRAY along with accessor functions
g_variant_new_objv, g_variant_get_objv and g_variant_dup_objv. Also add
support for '^ao' and '^a&o' format strings for g_variant_new() and
g_variant_get().
https://bugzilla.gnome.org/show_bug.cgi?id=654955
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
The function can be used to let regex compile non-NUL-terminated
strings without redesigning the way the pattern is stored in GRegex
objects and retrieved with g_regex_get_pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=615895
