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.
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);
^~~~~~~~~~~~~~~
This should maintain equivalent functionality, apart from that now you
have to pass `--force-fallback-for libpcre` to `meson configure` in
order to use the subproject; rather than specifying
`-Dinternal_pcre=true` to use the internal copy.
This also fixes#642, as the wrapdb copy of libpcre is version 8.37.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962Fixes: #642
This is basically a contrived test to trigger the `bytes->user_data !=
bytes->data` condition (and none of the earlier short-circuiting
conditions in that statement) in `try_steal_and_unref()`. This gives
100% line and branch coverage for `gbytes.c`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
A reader might think "how would a process terminate without an exit
status?", or equivalently, "what harm would it do if I assume every
termination has an exit status?" without this reminder that termination
with a signal is also reasonably common.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Unix platforms, wait() and friends yield an integer that encodes
how the process exited. Confusingly, this is usually not the same as
the integer passed to exit() or returned from main(): conceptually it's
an integer encoding of this tagged union:
enum { EXITED, SIGNALLED, ... } tag;
union {
int exit_status; /* if EXITED */
struct {
int terminating_signal;
bool core_dumped;
} terminating_signal; /* if SIGNALLED */
...
} detail;
Meanwhile, on Windows, wait statuses and exit statuses are
interchangeable.
I find that it's clearer what is going on if we are consistent about
referring to the result of wait() as a "wait status", and the value
passed to exit() as an "exit status".
GSubprocess already gets this right: g_subprocess_get_status() returns
the wait status, while g_subprocess_get_exit_status() genuinely returns
the exit status. However, the GSpawn family of APIs has tended to
conflate the two.
Confusingly, g_spawn_check_exit_status() has always checked a wait
status, and it would not be correct to pass an exit status to it; so
let's deprecate it in favour of g_spawn_check_wait_status(), which
does the same thing that g_spawn_check_exit_status() always did.
Code that needs backwards-compatibility with older GLib can use:
#if !GLIB_CHECK_VERSION(2, 69, 0)
#define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
#endif
Signed-off-by: Simon McVittie <smcv@collabora.com>
Zero is a valid TLS index so it needs to be checked. It’s also the
integer used to indicate that no TLS has been allocated yet, so it can’t
be used as a TLS identifier.
Incorporates changes from Philip Withnall.
Fixes: #2058
If there were more subpatterns in the regex than matches (which can
happen if one or more of the subpatterns are optional),
`g_match_info_fetch()` was erroneously returning `NULL` rather than the
empty string. It should only return `NULL` when the `match_num`
specifies a subpattern which doesn’t exist in the regex.
This is complicated slightly by the fact that when using
`g_regex_match_all()`, more matches can be returned than there are
subpatterns, due to one or more subpatterns matching multiple times at
different offsets in the string.
This includes a fix for a unit test which was erroneously checking the
broken behaviour.
Thanks to Allison Karlitskaya for the minimal reproducer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #229
Rather than predicating the test on whether the system PCRE is being
used, use a more specific version comparison which should work
regardless of whether the system or internal copy of libpcre is being
used.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962
Also move env setup earlier in the test, to ensure that
the child gets the envvars during initialization.
Also, don't look for exception codes in stderr, since
OutputDebugStringA() doesn't dump stuff there.
Use OutputDebugStringA() instead of fprintf.
The goal for this code is to inform the person running the debugger
about the exception that caused the debugger to be attached.
This is useful for debugging with gdb, because gdb does not catch Windows
exception information (it just displays "Segmentation fault").
OutputDebugStringA() ensures that the output goes to the debugger,
and the (ab)use of strcpy() with a stack-allocated buffer ensures
that we do not allocate anything while the crash handler is running,
nor to we call CRT functions that can be reasinably expected to allocate
anything.
Since VEH is invoked when an exception occurs (which, for us,
is mostly when the program is already crashing), we should
try to avoid doing much processing at that point. Since these
things (debugger commandline, a list of extra exceptions to catch)
are known in advance, set them up during initialization.
The first is to avoid any non-trivial code in the crash handler.
The second is to avoid the use of quarks and hash tables (brought
in by g_getenv()) during GLib initialization.
Update several links to allow the remote to use its configured default
branch name, rather than specifying `master` as the default branch name.
This will help avoid breakage if any of these projects rename their
default branch in the future.
Fix a few of the links where they were hitting redirects or had moved.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2348
