They return floating references. The convention established by GVariant
is to annotate these as (transfer none) so that the caller does a
ref+sink on them, rather than just a ref.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=677233
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.
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
GClosure has been in the "allocate area before the pointer" game since
before we did this with GTypeInstance. At the time that this was done
for GClosure, we didn't have valgrind.h in GLib.
Now that we do, we should add similar valgrind hints as the ones we did
for GTypeInstance. This substantially reduces reports of "possibly
lost" on pretty much any program that makes use of signals.
https://bugzilla.gnome.org/show_bug.cgi?id=739850
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
va_vopy() is not universally available in all compilers, so make use of
the existing G_VA_COPY macro which either calls va_copy() if it is
available, or emulates it if otherwise.
This means we're not abusing the notifiers for meta_marshallres,
and we're able to later cleanly add other fields to GClosure.
We still have to leave the ABI intact for the GClosure->meta_marshal
bit, as old G_CLOSURE_N_NOTIFIERS macro instances still accesses it.
However, we always set it to zero to keep those macros working.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
enums are stored in v_long but need to be marshalled as signed
integers. On platforms where int is 32 bits, taking the
address of v_long resulted in the wrong 32 bits being marshalled.
So we need to stuff the enum's int-sized value to a temporary
int-sized variable and marshall that instead.
Second, on return, libffi actually returns a pointer to a value
that's sized according to platform conventions, not according to
what the caller requested. ie if ffi_type_sint was requested, the
value can still be a 64-bit sign-extended long on a 64-bit
architecture like PPC64, thus the caller cannot simply cast
the return value as a pointer to the desired type, but must cast
as a pointer to an integral type and then cast to the desired
type to remove any sign extension complications.
For more information on how to correctly handle libffi return
values, see the following bug, specifically comment 35:
https://bugzilla.redhat.com/show_bug.cgi?id=736489
"For 64-bit ABIs that extend integral returns types to 64-bits, libffi always
returns full 64-bit values that you can truncate in the calling code. It's
just the way it is has always been. Please don't change libffi. I'll document
this clearly for the next version (perhaps there is a mention of this, I
haven't looked yet).
The same is true for returning 8-bit values, for instance, on 32-bit systems.
All ABIs extend those results to the full 32-bits so you need to provide a
properly aligned buffer that's big enough to hold the result."
https://bugzilla.gnome.org/show_bug.cgi?id=659881
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
The g_object_bind_property_with_closures() function should set a
marshaller if the two GClosures don't have one already. This simplifies
the caller code and avoids duplication.
We need to add a new marshaller to the gmarshal.list matching the
signature of the GBindingTransformFunc function.
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: remove trailing whitespace from newly added gtk-doc
comments and reformatted some where they contained overly long or
ill-formatted lines.
svn path=/trunk/; revision=7090
2008-06-22 Michael Natterer <mitch@imendio.com>
* *.c: moved includes back to the top of the files (before gtk-doc
SECTION comments). Add "config.h" in all files and move system
included before glib includes. Remove trailing whitespace from
SECTION comments and did some reformatting where lines were overly
long, no documentation content was changed.
svn path=/trunk/; revision=7089
