Glib cannot be built statically on Windows because glib, gobject and gio
modules need to perform specific initialization when DLL are loaded and
cleanup when unloaded. Those initializations and cleanups are performed
using the DllMain function which is not called with static builds.
Issue is known for a while and solutions were already proposed but never
merged (see: https://gitlab.gnome.org/GNOME/glib/-/issues/692). Last
patch is from version 2.36.x and since then the
"constructor/destructor" mechanism has been implemented and used in
other part of the system.
This patch takes back the old idea and updates it to the last version of
glib to allow static compilation on Windows.
WARNING: because DllMain doesn't exist anymore in static compilation
mode, there is no easy way of knowing when a Windows thread finishes.
This patch implements a workaround for glib threads created by calling
g_thread_new(), so all glib threads created through glib API will behave
exactly the same way in static and dynamic compilation modes.
Unfortunately, Windows threads created by using CreateThread() or
_beginthread/ex() will not work with glib TLS functions. If users need
absolutely to use a thread NOT created with glib API under Windows and
in static compilation mode, they should not use glib functions within
their thread or they may encounter memory leaks when the thread finishes.
This should not be an issue as users should use exclusively the glib API
to manipulate threads in order to be cross-platform compatible and this
would be very unlikely and cumbersome that they may mix up Windows native
threads API with glib one.
Closes#692
This function creates a new hash table, but inherits the functions used
for the hash, comparison, and key/value memory management functions from
another hash table.
The primary use case is to implement a behaviour where you maintain a
hash table by regenerating it, letting the values not migrated be freed.
See the following pseudo code:
```
GHashTable *ht;
init(GList *resources) {
ht = g_hash_table_new (g_str_hash, g_str_equal, g_free, g_free);
for (r in resources)
g_hash_table_insert (ht, strdup (resource_get_key (r)), create_value (r));
}
update(GList *resources) {
GHashTable *new_ht = g_hash_table_new_similar (ht);
for (r in resources) {
if (g_hash_table_steal_extended (ht, resource_get_key (r), &key, &value))
g_hash_table_insert (new_ht, key, value);
else
g_hash_table_insert (new_ht, strdup (resource_get_key (r)), create_value (r));
}
g_hash_table_unref (ht);
ht = new_ht;
}
```
This is a follow-up from commit 995823b9d9, which added the condition
```
```
to the array test. On most platforms, both of those symbols are numeric
literals, but on 64-bit Windows `G_MAXSIZE` includes some widening
casts, which means it can’t be used in a preprocessor condition.
We don’t expose an appropriate symbol in `glibconfig.h` which could be
used instead, but the standard `*_WIDTH` symbols from `limits.h` will be
identical and can be used instead.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2565
This mirrors what `wcwidth()` from glibc does as of June 2020 (commit
6e540caa2).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2564
Fix for commit 20c8ea1bc651bc4b79d39b80d42b468f6e7a2dc8; while Linux
seems happy to return the value for the invalid key we set above, BSD
returns NULL (which is probably a more valid thing to do).
Accept both.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This warning warns on widening casts from integer to pointer type,
because those casts can be problematic for porting to new pointer
sizes. The code in question didn't do any bad things here so an
intermediate cast to size_t was added to silence the warning
This test was exploiting unspecified behavior w.r.t. the address of string
literals, It expected them to be pooled (the same literal has the same
address, at least within a TU), but MSVC does not pool by default,
leading to a failure.
The tests were previously only checking the macro forms. The function
forms should behave identically, but since it’s easy enough to get
coverage of them, we might as well.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This decreases the overall test time from 0.17s to 0.12s for me, and
will help further in the following commit where I’m going to repeat some
of these calculations again for further comparisons.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously tests existed in two places,
`$top_srcdir/tests/sources.c` contained additional tests,
they have now been moved to `$top_srcdir/glib/tests/mainloop.c`
and `$top_srcdir/tests/sources.c` was deleted.
Related to: #1434
Previously tests existed in two places,
`$top_srcdir/tests/qsort-test.c` contained a similar test
to the one in `$top_srcdir/glib/tests/sort.c` called `test_sort_basic()`
The test for checking with zero elements was additional added to
`$top_srcdir/glib/tests/sort.c` and `$top_srcdir/tests/qsort-test.c`
was deleted.
Related to: #1434
The charset set in `CHARSET` overrides the charset after the `.` in any
`LC_*` category (set via the environment or `setlocale()`). This will
break many tests, but in particular it definitely breaks the
`/GDateTime/format_mixed/` tests which are specifically checking
different charsets being set for different `LC_*` categories.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2514
Currently `g_prgname` can be freed by `g_set_prgname()` while another
thread is holding a pointer to it.
We use GQuark when setting g_prgname so that string is never released once set.
Also added unit test, which checks if setting prgname in multi-threaded
program is safe.
Closes: #847
Some function such as atk_text_get_text, use -1 to indicate the end of the
string. And an crash occurs when the -1 is passed to g_utf8_substring.
Call Trace:
0 __memmove_avx_unaligned_erms
1 memcpy
2 g_utf8_substring
3 impl_GetText
4 handle_other
5 handle_message
6 _dbus_object_tree_dispatch_and_unlock
7 dbus_connection_dispatch
8 dbus_connection_dispatch
9 ()
10 g_main_dispatch
11 g_main_context_dispatch
12 g_main_context_iterate
13 g_main_context_iteration
14 g_application_run
15 main
Signed-off-by: Chen Guanqiao <chen.chenchacha@foxmail.com>
