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;
}
```
D-Bus reference implementation doesn't require more than the claimed
process SID as part of the AUTH initial data for EXTERNAL.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The code is based from #1351 patch and existing similar code in
gdbusprivate.c. The next commit will replace that existing code with
those helpers.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This code was skipping fsync on BTRFS because of an old guarantee about
the overwrite-by-rename behavior that no longer holds true. This has
been confirmed by the BTRFS developers to no longer be guaranteed since
Kernel 3.17 (August 2014), but it was guaranteed when this optimization
was first introduced in 2010.
This could result in empty files after crashes in applications using
g_file_set_contents(). Most prominently this might have been the cause
of dconf settings getting lost on BTRFS after crashes due to the
frequency with which such writes can happen in dconf.
See: https://gitlab.gnome.org/GNOME/dconf/-/issues/73
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
This commit puts an additional underscore before the external symbol
`_g_binary_test1_resource_data` when using gcc for Windows, to match
the compiler's expectation.
Fixes#2571
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Using ld_flags would work, but that does not propagate ldflags to users
of glib. Meson's dependency() call will propagate apple framework
dependencies to downstream users.
