Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
The alt-digits are loaded from `nl_langinfo()` in a `GOnce` section,
which means `nl_langinfo()` is not re-queried after the process changes
locale (if that happens).
So, change the `GOnce` to a mutex and store the locale of the alt-digits
alongside them. This will introduce contention when calling
`format_number()` is called, but how often are multiple threads trying
to format dates at the same time?
If this does get highlighted as a performance problem, the other
approach I considered was a `GPrivate` struct containing all the
locale-specific cached data. That comes at the cost of using a
`GPrivate` slot (although that’s only particularly expensive on Windows,
and the locale code is quite different for Windows, so perhaps that
could be avoided entirely). It does mean that all locale printing could
be lock-free and still safely update cached data on a locale change.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When calling `g_file_set_contents_full()` without
`G_FILE_SET_CONTENTS_CONSISTENT`, the file is written by opening it,
`write()`ing to it, then closing it.
This is fine as long as the file is not longer than the new content you
want to set its contents to. If it is, the last bit of the old content
remains, because `g_file_set_contents_full()` was missing an
`ftruncate()` call.
Fix that, and change the tests to catch truncation failures in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3144
The Windows x64 ABI follows the LLP64 model, so unsigned long int is 32 bits
Fixes the following warnings when compiling for Windows x64:
../glib/gobject/gatomicarray.c:85:3: warning: cast to smaller integer type 'unsigned long' from 'gpointer' (aka 'void *') [-Wvoid-pointer-to-int-cast]
VALGRIND_MALLOCLIKE_BLOCK (mem, real_size - sizeof (GAtomicArrayMetadata),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/glib/valgrind.h:6479:5: note: expanded from macro 'VALGRIND_MALLOCLIKE_BLOCK'
VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__MALLOCLIKE_BLOCK, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/glib/valgrind.h:203:15: note: expanded from macro 'VALGRIND_DO_CLIENT_REQUEST_STMT'
do { (void) VALGRIND_DO_CLIENT_REQUEST_EXPR(0, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/glib/valgrind.h:417:20: note: expanded from macro 'VALGRIND_DO_CLIENT_REQUEST_EXPR'
_zzq_args[1] = (unsigned long int)(_zzq_arg1); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See https://bugs.kde.org/show_bug.cgi?id=427146
g_strv_builder_take() allows to transfer ownership of the passed in
string.
This can be useful to avoid additional allocations when using functions
that transfer ownership to the caller like g_strdup_printf().
The testcase uses g_strv_builder_take and g_strv_builder_add to demo
that calls can be mixed.
We were initializing a DWORD (unsigned 32 bit) with a constant
of bigger rank (G_MAXSIZE) on 64 bit systems.
Fixes the following warnings on CLang when compiling for x64:
../glib/glib/tests/win32.c:47:14: warning: implicit conversion from 'unsigned long long' to 'DWORD' (aka 'unsigned long') changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
DWORD bp = G_MAXSIZE;
~~ ^~~~~~~~~
glib/glibconfig.h:88:19: note: expanded from macro 'G_MAXSIZE'
#define G_MAXSIZE G_MAXUINT64
^~~~~~~~~~~
../glib/glib/gtypes.h:107:21: note: expanded from macro 'G_MAXUINT64'
#define G_MAXUINT64 G_GUINT64_CONSTANT(0xffffffffffffffff)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
glib/glibconfig.h:69:52: note: expanded from macro 'G_GUINT64_CONSTANT'
#define G_GUINT64_CONSTANT(val) (G_GNUC_EXTENSION (val##ULL))
^~~~~~~~
<scratch space>:96:1: note: expanded from here
0xffffffffffffffffULL
^~~~~~~~~~~~~~~~~~~~~
Many toolchain did not change the definition of NULL to avoid introducing
breaking changes in existing codebases. For example, on Windows NULL is
0 (int) regardless of the C++ standard in use.
Fixes the following warnings on CLang when compiling for Windows:
../glib/glib/tests/cxx.cpp:539:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
../glib/gio/tests/cxx.cpp:62:34: warning: missing sentinel in function call [-Wsentinel]
g_test_init (&argc, &argv, NULL);
^
, nullptr
../glib/glib/gtestutils.h:298:9: note: function has been explicitly marked sentinel here
void g_test_init (int *argc,
^
