Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
I'm normally a big fan of small atomic commits, but I also want to get
things done this afternoon...
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687441
Reviewed-by: Colin Walters <walters@verbum.org>
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
"make check" was failing on sys/resource.h not being available on
win32. Seeing that this test just spews some numbers on stdout
whithout really testing anything we can safely replace them with
similar enough numbers by relying on g_get_monotonic_time ().
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=682386
gdb by default will only print strings up to 200 characters. After that
it abbreviates them. This affects the run-assert-msg-test.sh script if
the path to the glib installation is too long (in our case it was 133
characters, 132 would still have worked...)
By having gdb execute "set print elements 0" before printing the assert
string, the limit on maximum number of characters to print is set to
unlimited.
Signed-off-by: Peter Kjellerstedt <pkj@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=670218
These don't really matter, since it's test code, but they do obscure
real leaks in the library.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600161
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
These were the last users of the dynamic allocation API.
Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).
https://bugzilla.gnome.org/show_bug.cgi?id=660739
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
Replace it with g_thread_create_with_stack_size() and a real function
implementation of g_thread_create().
Modify a testcase that was calling g_thread_create_full()
inappropriately (it was using the default values anyway).
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
