In non-UTF-8 locales, the translations and nl_langinfo() return values
must be converted to UTF-8 before being returned to the caller.
Likewise, when making a recursive call to expand a format like '%x',
the format string must first be converted to UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=668250
break_lines uses LFs, not CRLFs like you might expect (since it's
designed for email-related use), but we can't change that now since
the caller has to allocate the output buffer and so the
number-of-bytes-output is part of the ABI. So, just document that.
https://bugzilla.gnome.org/show_bug.cgi?id=668158
This should help getting static builds working on mingw.
Based on a patch by Volker Grabsch, bug 619126.
At the same time, drop the unnecessary GLIB_RT_LIBS variable;
we are already adding -lrt to G_THREAD_LIBS.
Adding a child source to an already-attached parent source would
crash, because we were passing the parent's context when setting the
child's priority.
This is particular useful for:
g_array_new (sizeof (MyStruct), FALSE, FALSE);
because the correct incantation is
g_array_new (FALSE, FALSE, sizeof (MyStruct));
and these warnings will trigger in the first situation.
This is only supported on some compilers, so we define G_HAS_CONSTRUCTORS
when it is supported. However, when it is supported we guarantee that
both constructors and destructors work, in executables as well as shared
libraries (including runtime unloading of shared libraries).
Usage is a bit unorthodox, as some compilers need to use #pragma to
implement constructors, and #pragma can't be used in macros.
The canonical way to use this:
#ifdef G_DEFINE_CONSTRUCTOR_NEEDS_PRAGMA
#pragma G_DEFINE_CONSTRUCTOR_PRAGMA_ARGS(my_constructor)
#endif
G_DEFINE_CONSTRUCTOR(my_constructor)
static void my_constructor (void)
{
...
#ifdef G_DEFINE_DESTRUCTOR_NEEDS_PRAGMA
#pragma G_DEFINE_DESTRUCTOR_PRAGMA_ARGS(my_destructor)
#endif
G_DEFINE_DESTRUCTOR(my_destructor)
static void my_destructor (void)
{
...
g_thread_init() has done nothing since 2.32, so while the function
still can be used if "g_thread_init() has not yet been called",
it won't do nothing in that case, it will just perform normally.
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
When removing an item from the list, check the next one's my_owner,
and fix it accordingly. And take this case into account when last
of the list is deleted.
Also, assign NULL to 'my_owner' in g_thread_xp_WakeConditionVariable.
There are some races in the condition variable emulation code for
Windows XP with respect to timeouts while waiting.
First, in the event of a timeout, we never remove the waiter from the
condition variable. This can cause crashes later. That problem was
found by Rodrigo Rivas Costa.
Second, if the waiting thread times out and exits just as we were about
to call SetEvent() on its waiter event, we could end up trying to access
the waiter after it was closed/freed. We need to hold on to the lock a
little bit longer to ensure that that's not possible.
https://bugzilla.gnome.org/show_bug.cgi?id=666551
g_queue_free_full(), to free a Queue including its dynamically-allocated elements.
On similar lines to List and Slist.
void g_queue_free_full (GQueue *queue, GDestroyNotify free_func);
Test case covering g_queue_free_full() is added.
Added export symbol to glib.symbols.
Closes Bug: https://bugzilla.gnome.org/show_bug.cgi?id=657433
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
foo_free is conceptually "worth" one unref; not decrementing the
refcount here means the GArray or GPtrArray wrapper (but not its
contents) would leak in the following call sequence:
p = g_ptr_array_new ();
g_ptr_array_ref (p);
g_ptr_array_free (p, TRUE);
g_ptr_array_unref (p);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
First, some ARM systems are not fast enough to meet the 30 second
deadline in gwakeuptest.c, so increase that to 60.
Second, we have some signed/unsigned woes in the gparam transform tests.
On success, g_option_context_parse alters argv by removing options that
it understood, so g_strfreev is insufficient. Instead, take a shallow
copy and free all of the arguments in that, then free the array argv
but not its contents.
Also, improve the checks in error cases, by checking that argv has
not been altered in this way.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
