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
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
Per IRC discussion, we can just ask bindings to use
g_key_file_get_value() to test for the existence of a key.
I left the "fixed" code in the source tree as static because it makes
more sense to me.
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
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
Add a performance test for bitlocks.
Make use of the new g_atomic_int_{and,or} to avoid having to do the
usual compare-and-exchange loop.
On a test machine, the change increases performance from approximately
20 million uncontended acquire/releases per second to 31 million.
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
Make sure that the macros work properly with the range of types that
they are documented to work with and ensure that no strict aliasing
warnings are issued (even at the highest warning level).
https://bugzilla.gnome.org/show_bug.cgi?id=650935
