This is a step towards glib#1484. We officially require a C99 toolchain,
so we can statically assert that our artisanal hand-crafted integer
types are compatible with the ones we would like to recommend people
use instead.
If there are *still* platforms where <stdint.h> is problematic, these
static assertions can act as an early-warning that future GLib releases
will make a C99-compliant <stdint.h> a hard requirement, in ways that
are less straightforward to avoid (see glib#1484 and glib!1300).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Install a Vectored Exception Handler[0]. Its sole purpose is to catch
some exceptions (access violations, stack overflows, illegal
instructions and debug breaks - by default, but it can be made to catch
any exception for which a code is known) and run a debugger in response.
This allows W32 glib applications to be run without a debugger,
but at the same time allows a debugger to be attached in case
something happens.
The debugger is run with a new console, unless an environment variable
is set to allow it to inherit the console of the crashing process.
The short list of handleable exceptions is there to ensure that
this handler won't run a debugger to "handle" utility exceptions,
such as the one that is used to communicate thread names to a debugger.
The handler is installed to be called last, and shouldn't interfere
with any user-installed handlers.
There's nothing fancy about the way it runs a debugger (it doesn't even
support unicode in paths), and it deliberately avoids using glib code.
The handler will also print a bit of information about the exception
that it caught, and even more information for well-known exceptions,
such as access violation.
The whole scheme is similar to AeDebug[1] and, in fact, the signal-event
gdb command was originally implemented for this very purpose.
[0]: https://docs.microsoft.com/en-us/windows/desktop/debug/vectored-exception-handling
[1]: https://docs.microsoft.com/en-us/windows/desktop/debug/configuring-automatic-debugging
This commit adds two W32-only environmental variable checks:
* G_WIN32_ALLOC_CONSOLE, if set to 1, will force glib to create
a new console if the process has no console by itself.
This option is for GUI apps that are launched from GUI
processes, in which case there's no console anywhere near them.
* G_WIN32_ATTACH_CONSOLE, if set to a comma-separated list of
standard stream names (stdint, stdout, stderr), will reopen
a given std stream and tie it to the console (using existing console
or parent console).
This works either with the other option (to create a console),
or if the app is launched from a console process (often the
case for developers).
The redirection is done with freopen(), dup() and dup2().
If everything goes well, C file descriptors 0, 1 or 2 will
be bound to stdin, stdout and stderr respectively (only for
streams listed in the envrionmental variable), and so will
be stdio streams by the same names.
With these it's possible to see the output of g_log*() functions
when running GTK4 applications, which are linked as GUI applications,
and thus do not get a console by default.
https://bugzilla.gnome.org/show_bug.cgi?id=790857
Fixes issue #1304
ENABLE_GC_FRIENDLY_DEFAULT was supposed to set the default for the gc friendliness
while still allowing to force enable it at runtime with G_DEBUG=gc-friendly.
With commit 943a18b564 (6 years ago) things were changed to always set it
according to the content of G_DEBUG in glib_init(), making the default unused.
Since nobody complained since then just remove the macro and the build option.
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
The GVariant documentation says you can assume that types of no more
than 32 bits may be assumed to be promoted to int by the usual
promotions. If we're going to document that, we should statically
assert that it's true, i.e. sizeof (int) >= sizeof (int32_t).
All reasonable modern platforms are either ILP32 (32-bit platforms),
LP64 (64-bit Linux, *BSD etc.), or LLP64 (64-bit Windows): there have
been ILP64 platforms in the past, but ILP64 has the compelling
disadvantage that {signed char, short, int} can't possibly provide
all of {int8_t, int16_t, int32_t} unless int is 32 bits long.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters
ISO C allows compilers to make enums smaller than int if their
enumerated values would all fit in the range of a smaller type.
In practice, I suspect that in relevant compilers, all enums whose
values fit in the range INT32_MIN to INT32_MAX (inclusive) are the same
size as int. ISO C allows compiler to break that assumption, but those
that do would break code that works fine in other compilers, making the
compiler look bad, for no significant benefit. I conjecture that such
compilers are not popular.
Let's statically assert that my assumption holds. If all goes well,
GLib will continue to compile on every relevant platform; if it
fails to compile on some platform as a result of this change, then
there are probably a lot of naive uses of enums that need auditing
for this assumption.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Allison Lortie
This works by using semi-documented[1] exception to tell the debugger
that a thread needs to have its name changed.
If this exception is not caught and handled by something, it will crash
the process, so we need to set up our own handler in case there's no
debugger attached or the debugger can't handle this type of exception.
Since SEH is not supported by gcc on i686 (at the moment), we need to use VEH
instead. For completeness the MSVC-oriented code still uses SEH, although
there is no reason why it shouldn't work with the VEH variant used by MinGW.
VEH handler has to be set up somewhere (g_thread_win32_init () works nicely)
and removed once it's not needed (g_thread_win32_process_detach () is added
expressly for that purpose). Note that g_thread_win32_process_detach() is
only called when glib is unloaded by FreeLibrary(), not when glib-using
process is terminating.
This exception is known to work with WinDbg, and adding support for it into
GDB proved to be feasible (GDB patch will be sent upstream, eventually).
[1] https://msdn.microsoft.com/en-us/library/xcb2z8hs%28v=vs.71%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=747478
GLib has a pervasive assumption that function and data pointers are
basically interchangeable, which is true in all modern ABIs,
but not actually guaranteed by ISO C. If someone tries to use GLib on a
platform where function and data pointers are different sizes, fail early.
https://bugzilla.gnome.org/show_bug.cgi?id=688406
Currently g_mem_gc_friendly is declared in both gmem.h and glib-init.h
files, we will have reports on each unit that include these two files.
This patch removes the redundant declaration from glib-init.h
Since g_mem_gc_friendly is related to gmem.h and was first declared in
this header which also exports it via glib.h, then declare it in gmem.h
Other files already include gmem.h: garray.c and gslice.c, no need to
change anything.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
Any flags specified as well as "all" are subtracted from the result,
allowing the user to specify FOO_DEBUG="all,bar,baz" to mean "give me
debugging information for everything except bar and baz".
https://bugzilla.gnome.org/show_bug.cgi?id=642452
Instead of running the GPrivate destructors from our thread proxy code,
run it from the DllMain handler for the DLL_THREAD_DETACH case.
This should ensure that thread-local data is free at the exit of all
threads -- not just the ones we created for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=660745
