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
We have a GDateTime test that compares the time now (as per the libc) to
the time now (as per GDateTime). The problem is that the time could
change between those two "now"s.
At Tracker we want to mmap files using O_NOATIME. With GMappedFile this is at
the moment impossible. For that reason I added the constructor new_from_fd to
the GMappedFile type.
https://bugzilla.gnome.org/show_bug.cgi?id=659754
This reverts commit c7f9cd17d446938aaf4126e0753302676f66fd22.
The old macros in gthread.h used this variable, so it must remain in
place to keep ABI compatibility.
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).
This was ignored on Windows. On POSIX, where supported, it controlled
if we ended up with a proper system thread or a user-mode thread. Linux
did not support this.
Switch 'self' 'join' and 'create' from using the vtable to being called
via normal g_system_thread_* internal API (implemented in each of
gthread-{posix,win32}.c).
Again, we can put NULL in the vtable since these were never used from
gthread.h.
Thread priorities were already documented as not working on Solaris, and
they are meaningless on Linux unless the process separately requests
realtime scheduling (and even then, it appears only to work as root).
We can safely put a NULL into the vtable for set_priority since nothing
outside of gthread.c ever calls this (and that call is gone).
The "unknown reason" that the native thread implementation was broken is
because functions in kernel32.dll are (obviously) following Microsoft's
__stdcall ABI, not the GCC ABI.
Change our function pointers to be __stdcall pointers and change our
emulated implementation to match.
A pair of macros to define a constructor function (on compilers that
support such a concept) and to ensure that the function is run exactly
once (on compilers that lack such support).
Presently only GCC is implemented.
