Added the definitions below, as these #defines are needed for gqsort.c
#define ALIGNOF_GUINT32 4
#define ALIGNOF_GUINT64 8
#define ALIGNOF_UNSIGNED_LONG 4
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
Also, remove previous comments about sort stability in g_array_sort docs,
as the method that was explained does not work. Adds a new comment
about this.
https://bugzilla.gnome.org/show_bug.cgi?id=672095
We need a stable sort, and we might as well always use it rather
than have multiple sort versions. This picks up the glibc
merge sort implementation which it uses by default for qsort,
except we don't fall back to non-stable quicksort in some cases
like glibc
https://bugzilla.gnome.org/show_bug.cgi?id=672095
We check if the log level is in the "prefixed" list by checking it
against the g_log_msg_prefix bitfield.
Unfortunately we were failing to mask by G_LOG_LEVEL_MASK first, so if
the FATAL bit was set (for example) then it would never match. This was
the case for g_error().
https://bugzilla.gnome.org/show_bug.cgi?id=672026
The very last access to the 'depth' field of GStaticRecMutex in
g_static_rec_mutex_unlock_full() was being performed after dropping the
implementation mutex for the last time.
This allowed the lock to be dropped an additional time if it was
acquired in another thread right at that instant (which is somewhat
likely, since another thread could have just been woken up by the lock
being released).
https://bugzilla.gnome.org/show_bug.cgi?id=670846
Rename G_SPAWN_ERROR_2BIG to G_SPAWN_ERROR_TOO_BIG (while keeping the
old name for compatibility), to fix problems with language bindings
where the old name translates into something that would be
syntactically invalid due to starting with a digit.
https://bugzilla.gnome.org/show_bug.cgi?id=671025
g_sequence_lookup() only works on sorted sequences, but it's quite easy
to create unsorted sequences. Add a note to the documentation that the
sequence must be sorted in order for g_sequence_lookup() to work.
https://bugzilla.gnome.org/show_bug.cgi?id=670969
The version number we have here is the one the function appeared
in, not the max-allowed version. Therefore 'unavailable before
VERSION' makes more sense than 'unavailable for VERSION'.
There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
And clarify the memory allocation requirement of the string arrays passed to
g_environ_{,un}setenv().
==9458== 10 bytes in 1 blocks are definitely lost in loss record 16 of 39
==9458== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9458== by 0x4221A1F: vasprintf (vasprintf.c:78)
==9458== by 0x40C6065: g_vasprintf (gprintf.c:314)
==9458== by 0x409D894: g_strdup_vprintf (gstrfuncs.c:509)
==9458== by 0x409D8C9: g_strdup_printf (gstrfuncs.c:535)
==9458== by 0x40672E9: g_environ_setenv (genviron.c:156)
==9458== by 0x80490E7: test_environ_array (environment.c:78)
==9458== by 0x40A3DB5: test_case_run (gtestutils.c:1662)
==9458== by 0x40A40B2: g_test_run_suite_internal (gtestutils.c:1715)
==9458== by 0x40A417C: g_test_run_suite_internal (gtestutils.c:1726)
==9458== by 0x40A42F9: g_test_run_suite (gtestutils.c:1771)
==9458== by 0x40A3441: g_test_run (gtestutils.c:1319)
==9458== by 0x80493F1: main (environment.c:108)
Bug #669412.
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
(array) without (element-type) means "array of the same type as
the C type", so gchar* with (array) is interpreted as an array of
strings. Since GKeyFiles must be UTF-8 encoded anyway, just
annotate it as a string.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
When G_DISABLE_ASSERT is not defined, g_hash_table_foreach and
g_hash_table_find dereferences the hash table argument before
checking if it's NULL. This causes a crash when one of this function
is mistakenly called with a NULL argument instead of returning
with a warning through g_return_if_fail.
These tests were written, but then never used since it was decided to
add g_warnings() to goption.c in the cases they were supposed to be
testing. So anyway, just remove them.
When set to represent a zoneinfo file, TZ may start with :, therefore
glib needs to check it and ignore the first char when building the
resulting filename, or it won't be found.
Also, the path could be absolute, in which case it is wrong to
append /usr/share/timezone
https://bugzilla.gnome.org/show_bug.cgi?id=664237
==9458== 10 bytes in 1 blocks are definitely lost in loss record 16 of 39
==9458== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9458== by 0x4221A1F: vasprintf (vasprintf.c:78)
==9458== by 0x40C6065: g_vasprintf (gprintf.c:314)
==9458== by 0x409D894: g_strdup_vprintf (gstrfuncs.c:509)
==9458== by 0x409D8C9: g_strdup_printf (gstrfuncs.c:535)
==9458== by 0x40672E9: g_environ_setenv (genviron.c:156)
==9458== by 0x80490E7: test_environ_array (environment.c:78)
==9458== by 0x40A3DB5: test_case_run (gtestutils.c:1662)
==9458== by 0x40A40B2: g_test_run_suite_internal (gtestutils.c:1715)
==9458== by 0x40A417C: g_test_run_suite_internal (gtestutils.c:1726)
==9458== by 0x40A42F9: g_test_run_suite (gtestutils.c:1771)
==9458== by 0x40A3441: g_test_run (gtestutils.c:1319)
==9458== by 0x80493F1: main (environment.c:108)
Bug #669412.
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
GKeyFile supports empty files and also supports loading from the string
"", but will fail with a critical if you try:
- explicit length == 0
- data == NULL
length == 0 should always be valid, and data == NULL should be valid in
the case that length == 0, so add some testcases for those and fix the
code up to allow them.
https://bugzilla.gnome.org/show_bug.cgi?id=668756
And remove a comment about Windows in the fallback implementation that
no longer applies, since there's now a separate Windows-specific
implementation.
Like GPtrArray has a "free function" that can be used to free memory
associated to each pointer in the array, GArray would benefit from
having a "clear function" that can be used to clear the content of
each element of the array when it's removed, or when the entire array
is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=667243
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
Neither of those usages is valid, but there's a lot of use of 0 as a
domain "in the wild", so we can't g_return_if_fail yet.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=660371
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.
fix enables g_strescape() and g_strcompress() to handle '\v' along with other
special characters - '\b', '\f', '\n', '\r', '\t', '\'.
https://bugzilla.gnome.org/show_bug.cgi?id=664830
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
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>
Depending how the array is freed, we may want to free the underlying
array (the "segment"), the struct wrapper or both.
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>
These don't really matter, since it's test code, but they do obscure
real leaks in the library.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
Removing the last thing in a dataset frees the dataset, and if the
datalist was in a dataset, we can't safely unlock it after the dataset
has been freed. Unlock it sooner.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
Calling this function with a NULL argument is considered to be invalid,
but one of the regression tests does it anyway (to watch it crash), which
seems a good indication that it's expected to be somewhat common.
Let's check it rather than segfaulting.
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>
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
These were leaked. Valgrind was sad.
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>
Also document why we're not actually using the buffer for anything.
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>
In practice, the uninitialized refcount will typically mean that the copy is
never freed, and leaks.
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>
Raised by Matthias in bgo#665685 but which I didn't spot until after pushing
commit 3ac7c35656.
Renames G_UNICHAR_MAX_DECOMPOSITION_LEN to G_UNICHAR_MAX_DECOMPOSITION_LENGTH
and fixes a few documentation issues.
See: bgo#665685
These prevent GVariants from accidentally being brought back to life after
being freed, and should make it easier to track down ref. counting issues.
Closes: bgo#665184
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
The 1 bit mutex tests asserts: ((gsize) ptrs) % 8, ==, 0), which fails
when the platform only aligns porters to 32 bits (e.g. S390 and
powerpc).
I'm not sure why this assertion was placed here, but given
that internally g_pointer_bit_trylock uses g_atomic_int_or internally
change the assertion so it only requires the alignment to be a multiple
of sizeof(int)
