They do both accept NULL value arrays, but only if the number of
elements in the value array is zero. Fix the annotations and mention
this in the documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
See commit 4c2928a544 for why checking AT_SECURE is preferable compared
to UID checks as currently done in the fallback case.
getauxval() was added with glibc 2.16
While glibc <2.19 didn't provide a way to differentiate a 0 return value from an error,
passing AT_SECURE should always succeed according to
https://sourceware.org/ml/libc-alpha/2014-07/msg00407.html
I've added an errno check anyway, to be on the safe side.
It was added in 4c2928a544 to potentially enable accessing
AT_SECURE through __libc_enable_secure, but was never enabled.
Newer glibc provides getauxval(AT_SECURE) which should be used instead.
Add a TODO note for that.
ENABLE_GC_FRIENDLY_DEFAULT was supposed to set the default for the gc friendliness
while still allowing to force enable it at runtime with G_DEBUG=gc-friendly.
With commit 943a18b564 (6 years ago) things were changed to always set it
according to the content of G_DEBUG in glib_init(), making the default unused.
Since nobody complained since then just remove the macro and the build option.
g_date_strftime() on Windows uses the SYSTEMTIME structure which requires the
year to be >=1601. Passing 1 results in a negative SYSTEMTIME.wYear
which makes GetDateFormatW() fail and crashes due to missing error handling.
Just use 1976 as that's already used a few lines down.
Add a test macro that allows comparing two floating point values for
equality within a certain tolerance.
This macro has been independently reimplemented by various projects:
* Clutter
* Graphene
* colord
https://gitlab.gnome.org/GNOME/glib/issues/914
valgrind.h is a verbatim copy taken from Valgrind project. Previously
that file had local changes that got dropped by last update. To avoid
regressing again, do not edit valgrind.h anymore and instead add a
gvalgrind.h wrapper that gets included instead.
This fix 2 errors:
- uintptr_t is not defined when including valgrind.h on mingw.
- MSVC compiler is not supported on amd64-Win64 platform.
Better not modify copy/paster files otherwise this will regress again
later. It's better to not include valgrind.h at all when using MSVC.
This reverts commit bbcce75d4e.
The tests in test_async_queue_timed() assume that g_async_queue_timeout_pop()
and in turn g_cond_wait_until() wait at least until end_time
before returning, i.e. calling g_get_monotonic_time() after the timeout should result
in a value equal or larger than the timeout end time.
For the win32 implementation of g_cond_wait_until() this isn't the case which
makes those tests fail.
There are three reasons why the function returns early:
1) The underlying API works with milliseconds and the timeout gets rounded
down, resulting in a too small timeout value.
2) In case the timeout is too large to be passed to the API it gets limited
(there is also a bug because it converts INFINITE to milliseconds while
they already are, but using INFINITE would be wrong as well, as passing
a large timeout is not the same as blocking forever really)
3) Even with the rounding changed the underlying API still returns a bit early
sometimes on my machine (relative to g_get_monotonic_time())
This changes the implementation to round up to the next millisecond (fixing 1)
and to wait again in case a timeout occurs but the end time hasn't been
reached yet (fixing 2 and 3).
This makes the test_async_queue_timed() tests pass.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The timer tests expect that a small value for sleep does not result in
no sleep at all. Round up to the next millisecond to bring it more in line
with other platforms.
This fixes the glib/timer tests.
This makes the 'threadtests' time out since that uses small usleeps a lot and
until now didn't wait at all, but now always waits a msec. Reduce the amount
of tests done on Windows to get the runtime down to something reasonable again.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
For g_autolist and g_autoslist, the cleanup func was cast to
GDestroyNotify before being passed to g_(s)list_free_full. This cast
provokes GCC 8 to emit a warning if the return type is not void:
…/gmacros.h:462:99: warning: cast between incompatible function types
from … to 'void (*)(void *)' [-Wcast-function-type]
Cast to 'void (*)(void)' first, which suppresses the warning as
recommended by the GCC documentation. g_autoptr remains untouched.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1382
In commit f49a93b207
from bug https://bugzilla.gnome.org/show_bug.cgi?id=791342
we added two new static inline cleanup helpers in case a type was
used inside a list.
These functions will commonly be unused.
In rpm-ostree, we run a build using `CC=clang -Werror=unused` because
it catches `g_autofree char *foo = NULL;` as unused, but GCC doesn't.
When trying to update to F28 with a newer glib, our CI fell over on this.
Mark all of the autocleanups as "maybe unused".
Visual Studio x64 builds do not allow inline assembly code, so we need
to re-add the code that disables inline assembly when we build with
Visual Studio for x64 builds, as we did before. This is necessary when
we update the included valgrind.h.
The output of the %p type is implementation defined and on Windows we get
leading zeros depending on the pointer type size. Instead of adding
ifdeffery use g_snprintf() to generate the expected message.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
g_steal_pointer is both an inline function, returning gpointer, and a
macro that casts the return value to the type of its argument. The first
version of the macro uses '0 ? (*(pp)) : (g_steal_pointer) (pp)' to cast
the return value to the type of *pp, but this fails to yield warnings
about incompatible pointer types with current gcc. Apparently the
ternary operator is optimized away before the type of the expression is
determined.
The typeof() (or __typeof__()) operator allows an explicit cast.
https://bugzilla.gnome.org/show_bug.cgi?id=742456https://bugzilla.gnome.org/show_bug.cgi?id=796341
Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
The current docs implied, by using the printf name, that the macros would
be compatible with printf(), but that's not always the case.
On Windows we use gnulib if the system printf isn't good enough.
This can happen on MinGW without __USE_MINGW_ANSI_STDIO set or with MSVC
with a varrying degree of incompatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
This allows building with posix threads on Windows. It is generally
better to use win32 threads implementation on Windows, but this option
can be used in case it causes issues, or for performance comparison for
example.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
win32_cflags gets used globally as cflags and exposed in the .pc file.
win32_ldflags gets passed to glib-2.0 and exposed in the .pc file.
This should match what the autotools build is currently doing with
GLIB_EXTRA_CFLAGS and G_LIBS_EXTRA.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
• A leak of filename on an error path
• A leak of resolved_identifier if no out_identifier return location
was provided
The latter was spotted by Peter Bloomfield
(8945227743 (note_111254)).
Thanks!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
__MINGW32__ is defined on all MinGW variants including MinGW-w64.
__MINGW64_VERSION_MAJOR is only defined on MinGW-w64.
This difference is important because on MinGW-w64 we must #include
winternl.h because including ntdef.h results in compiler errors
about symbol redefinition, and the header warns that it is deprecated
and may be removed in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=795849
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
These make it easy to steal elements from pointer arrays without having
the array’s GDestroyNotify called on them, similarly to what’s possible
with g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
If using g_ptr_array_remove*() with a non-NULL GDestroyNotify function,
the value returned will probably be freed memory (depending on what the
GDestroyNotify) function actually does. Warn about that in the
documentation. We can’t just unconditionally return NULL in these cases,
though, since the user might have set the GDestroyNotify to a nifty
function which doesn’t actually free the element; so returning it might
still be valid and useful.
Also add missing (nullable) annotations to that documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
They were almost identically the same. This introduces no functional
changes, but will help with upcoming additions to GPtrArray.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
This is a combination of g_hash_table_lookup_extended() and
g_hash_table_steal(), so that users can combine the two to reduce code
and eliminate a pointless second hash table lookup by
g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795302
