We want to have the ability to mark types that should not be derivable
even if they are in a deeply derivable type hierarchy; in other words,
leaf nodes in the types tree.
When attempting to test Windows support for building libadwaita, since we are
using multiple GResource files, one would hit linker errors where multiple
definitions of the following symbols have been defined, when
glib-compile-resources was invoked without manual register:
resource_constructor_wrapper
resource_destructor_constructor
_arrayresource_constructor
_arrayresource_destructor
In order to avoid that, just prefix the definitions of resource_constructor
and resource_destructor, like what we do when --manual-register is used, with
what we pass in with --c-name so that we ensure that we do not end up in such
name collisions.
g_source_set_name duplicates the string, and this is
showing up as one of the more prominent sources of strdups
in GTK profiles, despite all the names we use being literals.
Add a variant that avoids the overhead.
Port all existing calls in GLib to the new API so that they can receive
more detailed error information (although none of them actually make use
of it at the moment).
This also serves to test the new API better through use.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #203
glib/grand.c:271:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'long long unsigned int'
for (i = 0; i < G_N_ELEMENTS (seed); i++)
^
glib/gthread-win32.c: In function 'g_private_get_impl':
glib/gthread-win32.c:310:16: warning: cast from pointer to integer of different size
DWORD impl = (DWORD) key->p;
^
glib/gthread-win32.c:315:14: warning: cast from pointer to integer of different size
impl = (DWORD) key->p;
^
glib/gthread-win32.c: In function 'SetThreadName':
glib/gthread-win32.c:596:60: warning: passing argument 4 of 'RaiseException' from incompatible pointer type
RaiseException (EXCEPTION_SET_THREAD_NAME, 0, infosize, (DWORD *) &info);
^~~~~~~~~~~~~~~
The `g_file_trash` function fails with the `Unable to find or create trash
directory` error when the global `.Trash` directory exists. This is because
the commit 7f2af262 introduced the `gboolean success` variable to signalize
the detection of the trash folder, but didn't set it in all code branches.
Since for a time this variable was not initialized the bug wasn't visible
when the trash folder existed. The bug became effective after the `success`
variable was initialized with `FALSE` by the commit c983ded0. Let's explicitly
set the `success` variable in all branches to fix the global trash dir
detection.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2439
It’s a new flag added to `close_range()` in kernel 5.11, which will
allow us to speed up setting `CLOEXEC` on ranges of file descriptors.
This currently happens in some situations when executing a new binary
with `GSpawn`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The function which calls `SetFileTime()` works with seconds and
nanosecond, but the functions which call it are doing so with seconds
and microseconds.
Fix them so they convert to nanoseconds first.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code appears to be dealing with time in units of 100ns, not 100µs,
so name the variable accordingly.
The rest of the arithmetic in that function appears consistent and
correct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The modification time test creates a file, gets the modification time in
seconds, then gets the modification time in microseconds and assumes
that the difference between the two has to be above 0.
As rare as this may be, it can happen:
$ stat g-file-info-test-50A450 -c %y
2021-07-06 18:24:56.000000767 +0100
Change the test to simply assert that the difference not negative to
handle this case.
