Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.

This commit was entirely generated using the command:
```
git ls-files glib/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #1415

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: #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 ...

According to build system (meson.build file), G_PLATFORM_WIN32 and G_OS_WIN32
are synonym. This commit just unify the usage of this define to prepare
for the static build conditional compilation code.

Krzesimir Nowak authored Dec 25, 2019 and Philip Withnall committed Jan 06, 2021

This commit adds a G_DEFINE_EXTENDED_ERROR macro and
g_error_domain_register() functions to register extended error
domains.

This is a step towards #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 #1484 and !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 943a18b5 (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.aspx

https://bugzilla.gnome.org/show_bug.cgi?id=747478

This will be used in the next commit to call glib_init from the
gobject constructor, to ensure proper constructor ordering with
non-GNU libc.

https://bugzilla.gnome.org/show_bug.cgi?id=756139

This will be needed to fix constructor order for non-GNU libc.

https://bugzilla.gnome.org/show_bug.cgi?id=756139

This removes a branch from the very frequently called
quark functions.

configure.ac assumes this.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932

Switch to simpler markdown, `foo`.

Simon McVittie authored Nov 16, 2012 and Matthias Clasen committed Jan 19, 2014

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

Djalal Harouni authored Oct 20, 2013 and Dan Winship committed Oct 20, 2013

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

LRN authored Apr 09, 2013 and Alexander Larsson committed Apr 09, 2013

All tests pass with this patch AND a good pthreads implementation
(i'm using winpthreads, not pthreads-w32).

https://bugzilla.gnome.org/show_bug.cgi?id=697626

https://bugzilla.gnome.org/show_bug.cgi?id=688109

In the glib-init shuffle this ended up being set to no messages prefixed
by default.  Fix that so that we have prefixes back.

https://bugzilla.gnome.org/show_bug.cgi?id=672026

No need to hand-roll this when we have a macro version.

Stef Walter authored Dec 13, 2011 and Matthias Clasen committed Dec 13, 2011

Fixes for gtk-doc warnings.

http://bugzilla.gnome.org/show_bug.cgi?id=66469

https://bugzilla.gnome.org/show_bug.cgi?id=664699

Will Thompson authored Oct 20, 2011 and Matthias Clasen committed Oct 24, 2011

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

Move the last few things that needed thread-safe initialisation to a
global ctor.

https://bugzilla.gnome.org/show_bug.cgi?id=660744