Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.
Based on the patch by Christian Persch and Emmanuele Bassi.
Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=590808
gutils.[hc] is a bit of a grab bag, so lets start cleaning
things up by moving all the environment-related functions
into separate genviron.[hc] files.
The private _g_getenv_nomalloc has been moved to its sole caller.
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
01ed78d525 introduced assertion checks for
creating a main context, forking, and attempting to use the main context
from the child side of the fork.
Some code (such as gnome-keyring-daemon) daemonise after calling
GMainContext. That's probably still mostly safe since we still only
have one side of the fork touching the context afterwards.
This use case is still troubling, however, since if any worker threads
have been created at the time of the fork(), we could end up in the
classic situation of leaving some mutexes in a locked state when the
other threads disappear from the copy of the image that the child gets.
This will require some deeper thinking...
Some code using GLib (gnome-keyring-daemon, for example) assumes that
they can catch signals by masking them out in the main thread and
calling sigwait() from a worker.
The problem is that our new worker thread catches the signals before
sigwait() has a chance and the default action occurs (typically
resulting in program termination).
If we mask all the signals in our worker, then this can't happen.
Switch GCond to using monotonic time for timed waits by introducing a
new API based on monotonic time in a gint64: g_cond_wait_until().
Deprecate the old API based on wallclock time in a GTimeVal.
Fix up the gtk-doc for GCond while we're at it: update the examples to
use static-allocated GCond and GMutex and clarify some things a bit.
Also explain the rationale behind using an absolute time instead of a
relative time.
Hide the definition of struct _GThread in gthreadprivate.h for now.
This is possibly an API break -- although the structure contents were
undocumented and it was not safe to access them in a meaningful way,
someone may have tried to do it anyway. We'll leave it here for a while
to see if it causes any problems.
Avoid merging its contents with GRealThread for now, just incase we need
to expose it again.
We'll hold out on this until someone has a really convincing reason for
why they need to control the stack size.
If we do decide to add it back, it should probably have a name like
_new_with_stack_size(), not _full().
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().
Change the wording in the docs. Clarify expectations for
(deprecated) g_thread_create().
GThread is freed using some very slightly confusing logic: if the thread
was created 'joinable', then the structure is freed after the join()
call succeeds (since we know the thread has exited). If the thread was
not created 'joinable' then the free is when the thread quits (since we
know 'join' will not be called later).
Move to a straight ref-counting system: 1 ref owned by the thread and 1
extra ref if the thread is joinable. Both thread quit and joining will
decrease the refcount by 1.
Make the POSIX backend a little bit more like the win32 one in terms of
how we deal with joinability.
Calling g_system_thread_join() is now optional, and
g_system_thread_wait() can be safely called by multiple threads.
There is no longer any internal concept of joinability.
Merge the GThreadData with the GThreadWin32 struct. Drop the extra TLS
variable.
Close the handle on _free(), which means that there is no leak if
g_system_thread_join() isn't called.
Remove all internal concept of joinability.
Keep track of if we created a thread for ourselves or if the GThread*
was allocated in response to g_thread_self() on a previously-unknown
thread.
Only call g_system_thread_free() in the first case.
Wrap GRealThread in a GThreadPosix that includes its own pthread_t field
called "system_thread" and use that instead of the generic field in
GRealThread.
Add g_system_thread_new() and g_system_thread_free(), implemented with
GSlice. Use those instead of g_new() and g_free().
Presently, the backends are both doing the same thing. This will change
soon.
The use of system_thread is now limited to joining. We don't do that
for threads that we didn't create for ourselves, so we don't need to
call g_system_thread_self() to fill in system_thread for those.
...instead of having a 'next' pointer in the GThread struct.
Now GThread contains no fields used only by deprecated code (except for
the rather generic setup function field).
Thanks to the modifications in 3d4846d923,
GStaticPrivate is not so directly tied in with GThread anymore. It is
now a simple matter to cut it out completely by using a GPrivate to
store the GArray instead of storing it in the GThread.
Unlike G_GNUC_... macros, the new G_DEPRECATED[_FOR] are
meant as abstractions that work with different compilers.
Using a new name also lets us restrict it to 'must be placed
before the declaration', which works with more compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=661438
The definitions of _GMutex* and G_STATIC_MUTEX_INIT is now found in
glib/deprecated/gthread.h, and should no longer be in the mainline
code, so remove them from here.
Everything was OK as long as GMutex was backed by pthread_mutex_t on
POSIX. Since this is no longer the case, the ABI of GStaticMutex was
broken.
Fix that up by using pthread_mutex_t directly in the structure. Since
that's potentially incompatible with our GMutex implementation, set
g_thread_use_default_impl to FALSE to cause the fallback code (which
manually allocates a GMutex) to run, even in the case of
already-existing code (without the need for a recompile). This will
cause the pthread_mutex_t part of the struct to be completely ignored.
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
I've seen builds fail with
nm-connection.c:119:691: error: declaration of '_GStaticAssertCompileTimeAssertion_119' shadows a previous local [-Werror=shadow]
because several compile-time assertions ended up on the same
line. __COUNTER__ is meant specifically for the purpose of
constructing identifiers, so use it when available.
0e3f530185 introduced a compiler warning
about implicit declaration of g_get_prgname(). Fix that.
Problem caught and fix suggested by Rico Tzschichholz.
We can just assume that strerror/strsignal are available
nowadays. At the same time, drop use of thread-private storage.
Instead, always return interned strings.
https://bugzilla.gnome.org/show_bug.cgi?id=660849
GTimer no longer uses the thread system for time information and
g_thread_init() no longer does anything, so remove the doubly-untrue
warning about these topics.
https://bugzilla.gnome.org/show_bug.cgi?id=527214
We can't initialise gslice from a ctor because g_slice_set_config() must
be called before gslice initialisation.
Instead, do the initialisation in a threadsafe way from the
initialisation function for the thread private data. This will only be
called once per thread so the synchronisation doesn't pose a significant
overhead here.
Ensure that we try to grab the thread private data directly on entrance
to g_slice_alloc() so that we force the initialisation to occur.
Grabbing the private data is the common case anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=660887
Instead of running the GPrivate destructors from our thread proxy code,
run it from the DllMain handler for the DLL_THREAD_DETACH case.
This should ensure that thread-local data is free at the exit of all
threads -- not just the ones we created for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=660745
Make sure that it calls absolutely nothing that may ever recurse back
into GLib again:
- g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at
the top. As far as I know, the only ASCII character letter that
would get special treatment here is "i" and that appears in neither
"help" nor "all".
- g_getenv() is very complicated on Windows, so use a simple version
that is sufficient for our purposes.
Now that it's completely safe, we can just call it from g_logv() in the
usual way without all of the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=660744
Give the macro wrapper treatment to g_once_init_enter() and leave() in
the same style that we did for gatomic.
It is now possible to use these macros with any pointer-sized object,
and not just gsize. The leave() macro ensures that the initialisation
result is a compatible type with the pointer that it is being written
to.
Just like with gatomic, there could be problems caused by use of (void*)
casts. We'll see how that goes, and reevaluate if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=660743
Presumably, the rationale for not storing the endianness is that
GVariant is a recursive type system, and in a sane format, endianness
only needs to be stored once per blob of data (once per D-Bus message,
once per file on disk, etc.).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Also include a shorter version in the docs for g_variant_store, with a
pointer to g_variant_get_data.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Strings matching /%[a-z]/ are special syntax for gtk-doc.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
This covers the str, double, int, int64 hash and equal functions, but not
anything that takes an "object", since the convention is that "object
methods" never accept NULL anyway.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Also annotate them as (allow-none), more for the benefit of gtk-doc
readers than introspection.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Using g_int_hash, g_int_equal with keys like GINT_TO_POINTER (n) seems to
be a reasonably common GLib-novice mistake. It doesn't help that the
documentation for GHashFunc was ambiguous about this.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The copying of code from g_async_queue_new() to g_async_queue_new_full()
in ef08aa786b copied the setting of the
free function to NULL (instead of the one passed in by the user).
Fix that up so that the test passes again.
https://bugzilla.gnome.org/show_bug.cgi?id=660843
The markup here was not only broken, it was also unnecessary,
since gtk-doc knows to apply <function></function> tags to things
that end with () already.
Add a little bit more room in the ABI for our synchronisation primatives
since we're going to need it when we add native implementations on
Linux.
Also: rename the pointer field and add /*< private >*/ annotations.
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
Modify the POSIX implementation of the synchronisation primatives to use
the same ABI as Windows: one pointer for each type.
This frees us from having to #include <pthread.h> and avoids the problem
with pthread_rwlock_t not being defined under certain compiler defines.
A few more changes are expected to the ABI -- they will be committed
separately.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
This commit moves GStaticPrivate, g_thread_foreach and all
related functions and variables to gthread-deprecated.c. We
introduce some internal API to make this possible.
g_thread_foreach is not a very useful function, since there is
virtually nothing you can do with a GThread*, and implementing
it requires us to keep a list of threads around.
GStaticPrivate has been made redundant by adding comparable
capabilities to GPrivate.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.
Change GThreadPool, GMainContext and GDBus to create named threads.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
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().
To avoid iterating threads in g_static_private_free(), defer freeing
the per-thread data to thread exit. The one complication here is
that it is possible for the static private index to be reused while
'old' data is still around. To deal with that case, store the 'owner'
with each per-thread data node, and free old data in
g_static_private_get() if the owner doesn't match. The remaining
possibility that a private index could be reused by a GStaticPrivate
with the same address is sufficiently unlikely that we can probably
ignore it.
With this change, per-thread data is now truly private again,
and we can drop the lock for it as well.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
We lack SRWLock on Windows XP, so we use CRITICAL_SECTION to emulate it
there. SRWLock is non-recursive, but CRITICAL_SECTION will happily
allow itself to be acquired multiple times by the same thread.
We need to detect if our second acquire succeeded because of the
recursive nature of CRITICAL_SECTION. In the case of a _lock()
operation, we would normally have deadlocked, so abort. In the case of
a _trylock() operation, we need to ensure that FALSE is properly
returned.
Problem caught by Matthias Clasen and Chun-wei Fan.
https://bugzilla.gnome.org/show_bug.cgi?id=660096
-Include gthread.h in gregex.c as g_once_init_enter and g_once_init_leave
are used.
-Define prototype for g_thread_DllMain in gthreadprivate.h for Windows
-Fix GLib project/filter files generation as some source items are under
the "deprecated" subfolder, and filter out the gthread-*.c
-Explicitly specify gthread-win32.c in the GLib project/filter file
templates, since tarballs are done on Linux.
-Don't define g_static_mutex_get_mutex in the pregenerated
glibconfig.h.win32(.in) as it is defined in deprecated/gthread.h for Windows
We have a GDateTime test that compares the time now (as per the libc) to
the time now (as per GDateTime). The problem is that the time could
change between those two "now"s.
At Tracker we want to mmap files using O_NOATIME. With GMappedFile this is at
the moment impossible. For that reason I added the constructor new_from_fd to
the GMappedFile type.
https://bugzilla.gnome.org/show_bug.cgi?id=659754
This reverts commit c7f9cd17d446938aaf4126e0753302676f66fd22.
The old macros in gthread.h used this variable, so it must remain in
place to keep ABI compatibility.
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).
This was ignored on Windows. On POSIX, where supported, it controlled
if we ended up with a proper system thread or a user-mode thread. Linux
did not support this.
Switch 'self' 'join' and 'create' from using the vtable to being called
via normal g_system_thread_* internal API (implemented in each of
gthread-{posix,win32}.c).
Again, we can put NULL in the vtable since these were never used from
gthread.h.
Thread priorities were already documented as not working on Solaris, and
they are meaningless on Linux unless the process separately requests
realtime scheduling (and even then, it appears only to work as root).
We can safely put a NULL into the vtable for set_priority since nothing
outside of gthread.c ever calls this (and that call is gone).
The "unknown reason" that the native thread implementation was broken is
because functions in kernel32.dll are (obviously) following Microsoft's
__stdcall ABI, not the GCC ABI.
Change our function pointers to be __stdcall pointers and change our
emulated implementation to match.
A pair of macros to define a constructor function (on compilers that
support such a concept) and to ensure that the function is run exactly
once (on compilers that lack such support).
Presently only GCC is implemented.
We remove the macros while at the same time switching all libglib users
from g_private_new() to g_private_init(). We deal with the strange
expectations of the libglib code that g_private_* should work before the
GPrivate has been initialised with a temporary shim.
- expose the structure types for GLib internal use only
- avoid infinite recursion hazards by ensuring that GPrivate never
calls back into any other part of GLib
- substantially rework the Windows implementation so that it never
holds locks, contains no arbitrary limits and doesn't waste
100*sizeof(void*) per thread
We have to keep the macro hacks for the time being since some code
inside libglib depends on it.
Now that GMutex is exposed we can avoid the dance we did in ./configure
to allocate the correct amount of space for it within the GStaticMutex.
Remove the checks and move the definitions to gthread.h, trying very
hard to keep ABI-stable (even though we will be deprecating this soon).
The original GMutex/GCond rework patch introduced some temporary code to
cope with GLib's old approach to thread initialisation. These are no
longer required.
Now that nothing inside of GLib is using g_cond_new(), we can implement
it using GSlice. Since the implementations for POSIX and Windows are
now the same, move it to gthread.c.
Now that nothing inside of GLib is using g_mutex_new, we can implement
it using GSlice. Since the implementations for POSIX and Windows are
now the same, move it to gthread.c.
Do a substantial rework of the GMutex and GCond APIs.
- remove all of the macro indirection hackery which is no longer needed
since we dropped support for switchable thread implementations
- expose the structure types and add G_MUTEX_INIT and G_COND_INIT
static initialiser macros
- add g_mutex_init() and g_mutex_clear() for use when embedding GMutex
into another structure type and do the same for GCond as well
- avoid infinite recursion hazards by ensuring that neither GCond or
GMutex ever calls back into any other part of GLib
- substantially rework the Windows implementation of GCond and GMutex
to use the SRWLock and CONDITION_VARIABLE APIs present on Windows
2008/Vista and later, emulating these APIs on XP
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
Implement g_ascii_strto{d,ll,ull} and g_ascii_formatd using
xlocale functions where available. This is slightly faster
and a lot less icky than our homegrown code.
https://bugzilla.gnome.org/show_bug.cgi?id=640293
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
GStaticMutex makes use of atomic operations to initialise itself. We
were using GStaticMutex from the emulated case of gatomic. Use pthreads
directly to avoid unbounded recursion in this case.
This variable, which is the cause of much grief, exists for two reasons:
- ensuring the the wakeup pipe doesn't fill up
- preventing the first poll() after adding a source from waking up
immediately
The first point is no longer an issue with GWakeup.
The second point is addressed by using different logic: we only signal a
wakeup in the case that the context is currently acquired by a thread
that is not us.
As an added bonus, we can now implement g_main_context_wakeup() without
taking a lock.
https://bugzilla.gnome.org/show_bug.cgi?id=583511https://bugzilla.gnome.org/show_bug.cgi?id=320888
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
Remove the explicit thread initialisation functions for g_get_charset(),
g_get_filename_charsets() and g_get_language_names().
Add a lock around one remaining case of access to libcharset (the other
2 cases already have the lock).
Do a proper g_once_init_enter() style initialisation for the GLib
gettext functions.
https://bugzilla.gnome.org/show_bug.cgi?id=658683
Historically we've added random symbols to the public API with warnings
that they're private; examples are:
glib_gettext(), glib_pgettext()
g_thread_functions_for_glib_use, g_thread_use_default_impl, etc.
And we almost added "GWakeup" to public API just to share between glib and
gio.
This new glib__private__() API exports a hidden vtable, and adds a macro
GLIB_PRIVATE_CALL() that makes it generally convenient to use.
This adds an extremely tiny cost for the double indirection; but it has
the benefit that we don't need to either:
1) compile the code into both glib and gio (like GWakeup), with the
inefficiency that implies.
2) Export a "do not use this" symbol; the serious problem with this is
that someone CAN use it pretty easily. Particularly if we document
it. It's far, far harder to peek into a structure without a public
header file.
https://bugzilla.gnome.org/show_bug.cgi?id=657992
Since GMainLoop is now purely monotonic, it really doesn't make sense to
cache the wallclock time just for the sake of making a deprecated call
more efficient.
The first time this is called, this creates a GMainContext * and a
thread to run it. Future calls return the same. There are a lot of
places that we could use this in GLib.
g_thread_gettime() is an undocumented public function pointer that
points to a function that returns the monotonic time in nanoseconds.
g_get_monotonic_time() does the same in microseconds, so it can be used
instead.
GLib had one internal user in GFileMonitor that only cared about
millisecond accuracy; it has been ported to g_get_monotonic_time().
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
We had the 12 hour time format hard-coded to "%02d:%02d:%02d %s" but it
actually changes depending on the locale. Just with the other formats,
use nl_langinfo() if we have it, otherwise fall back on gettext().
Improve a few situations where g_date_time_format() was getting the
padding wrong when displaying alt digits (eg: Arabic numerals) for
formatting time.
We now depend on nl_langinfo (_NL_CTYPE_OUTDIGITn_WC) to do the
conversion, which is very likely glibc-specific, but our previous method
relied on a glibc-specific printf() feature, so no harm done there.
Add a configure check for nl_langinfo (_NL_CTYPE_OUTDIGITn_WC).
Uncomment a few testcases that were failing previously.
https://bugzilla.gnome.org/show_bug.cgi?id=658107
Explicitly mention C99's strftime() in the documentation for
g_date_time_format() as the one that we aim for compatibility with.
Specifically list the formats we do not support as well as the extra
ones that we borrow from glibc.
Test g_date_time_format() against strftime(). This test found quite a
few cases of incorrect behaviour on our part (fixes already committed
for those).
Our implementation of %W is incorrect. Nobody should want to use this
format anyway and the implementation is non-trivial, so rip it out
rather than fixing it.
Remove the testcase for %W as well.
%N is not specified in any standards document, but we use it to display
the number of microseconds.
The fact that our our current implementation of it is nearly useless
(since it does not zero-pad) coupled with the high chance that a future
version of the C standard may specify it with another meaning means that
we should drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=658061
%V represents the ISO 8601 week number of the current year as a
decimal number, range 01 to 53, where week 1 is the first week
that has at least 4 days in the new year
https://bugzilla.gnome.org/show_bug.cgi?id=658061
Since there was nothing guaranteeing synchronization of the
assignments to checked and clockid, it would be possible for one
thread to set clockid = CLOCK_MONOTONIC, and for another thread to see
checked = TRUE but still clockid = CLOCK_REALTIME.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
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
This makes the source efficient on Linux.
Tested on Fedora 15 x86_64 + updates, kernel-2.6.40-4.fc15.x86_64
Also tested fallback code for unsupported flag TFD_TIMER_CANCEL_ON_SET
on kernel 2.6.38.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
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 makes g_date_time_format() react to LC_TIME, which is
what people expect.
Translators: this change means that the GDateTime strings
are only used when the C library does not already provide
suitable translated strings for these (month names, etc).
Posix allows for open(2) to fail with errno = EINTR.
Normal this isn't seen when opening files. However in some case we are
opening a fifo for write which will block until another process opens it
for read. If a signal is received while blocked, open(2) fails with
errno = EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=656492
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
The long format that displays the exact number of bytes with separators
(ie: "123,456,789 bytes") uses the ' format modifier, which is
unsupported on Windows. Disable that for now, until we come up with a
better solution.
GWakeup is a utility class to handle the cross-thread signalling needs
of GMainContext and GCancellable. It may find some other users as well.
The desire here is to properly hide the implementation details in a
module which can be properly unit tested and used in GMainContext and
GCancellable without a rats nest of #ifdef.
Fix some bugs in the fallback case of g_unix_open_pipe:
- close both halves of the pipe on error (not just one)
- set the cloexec flag on both halves of the pipe (instead of settings
it twice on one half)
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.
If gtk-doc sees 'Returns ...' written in the text of the documentation
for a macro, it thinks that you are talking about the return value.
Avoid doing that and use 'Returns:' explicitly if we mean to.
David requested that I change the order of the flags.
Also, assign numerical values to the flags in the usual way. This
wasn't a bug yet, but only by chance.
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)".
Rename the size constants from KILOBYTE to KIBIBYTE (etc.) since that's
what they really are.
This is a strictly internal change with no externally-visible effect in
terms of API or functionality.
The choice between g_variant_iter_next() and g_variant_iter_loop() is a
bit confusing for some people. Add a note to the documentation of
g_variant_iter_loop() to clarify that it should be avoided except in a
few specific cases.
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
Previously, when a binary did not run a single test - for whatever
reason, from the binary not existing to the binary not using the gtester
framework - no failures were recorded. Now we record a non-successful
run of a binary that did not start any tests as a failure, too.
Note that this does not change the behavior of any binaries that exit
successfully or that report the start of any gtester test.
Previously, gtester used the testcase_fail_count as the number of tests
that failed in the latest run testcase, but then use that as the return
value of main().
Now we count the failed testcases of the whole run.
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
The -e parameter to echo isn't recognized by echo in POSIX sh,
but isn't needed when no escaped characters need to be
interpreted.
This fixes building glib with a mingw cross compiler on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=654085
