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
