It's not likely that the runtime of a bound language using the
introspection supports running in a process forked by a foreign
library, so that a closure programmed in that language would work
safely.
Any programming environment supporting that would probably have
its own advanced facilities for process spawning, or be able
to access the GLib spawning APIs via raw C bindings (still
represented in the introspection, (skip) only adds a flag)
and do any low-level preparatory dances as necessary for the
forked runtime.
Note that there are other APIs making use of GSpawnChildSetupFunc,
but they are usable with the closure nullified, and we cannot annotate
the closure parameters away because that would break the annotated API
for bindings; accordingly to bug #738176 comment #3, the current bindings'
users are expected to pass null.
It's ugly:
- The core method, g_iconv(), can't be annotated with good semantics.
- The error value of g_iconv_open() is not representable in today's
introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=756128
The length of the caller-allocated (that flag was missing; added as well)
output array is calculated by a formula, so none of the usual array length
annotations apply. The state parameters need to be initialized with zero.
Just let them use the basic API.
https://bugzilla.gnome.org/show_bug.cgi?id=756103
The functions with a GDestroyNotify to the data, or other ill-fitting
allocation semantics, are not currently introspectable.
The effect for the binding user would be that they're unable to
create or destroy a GData list, but they might still have an API
to poke at some data pointers from it.
In fact, none of the functions dealing with GData** or a dataset
location pointer are likely to get sensible bindings anyway;
the annotations added are mostly to avoid memory unsafety
and leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=756470
This supports a subset of ISO 8601 since that is a commonly used standard for
storing date and time information. We support only ISO 8601 strings that contain
full date and time information as this would otherwise not map to GDateTime.
This subset includes all of RFC 3339 which is commonly used on the Internet and
the week and ordinal day formats as these are supported in the GDateTime APIs.
(Minor modification by Philip Withnall to change API versions from 2.54
to 2.56.)
https://bugzilla.gnome.org/show_bug.cgi?id=753459
Make it a bit more obvious when the DTLS methods aren’t implemented by a
particular TLS backend; return an invalid type rather than crashing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752240
This was duplicated also in g_object_interface_install_property().
Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=787551
In the Dictionary section of the gvariant-format-strings documentation
only how to construct a dictionary is shown.
Add a small example showing how to extract data from a nested dictionary
and specifically from a GVariant of type "(oa{sa{sv})". Move also the
Dictionary section after the GVariant * section for the sake of clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=786737
Instead of a full reference, which causes problems for clients that
expect a GSettings instance to stop firing signals once they drop the
last reference.
https://bugzilla.gnome.org/show_bug.cgi?id=780861
Explain the default values of _{get,set}_close_on_unref() in the main
description rather than the argument one, link to the GIOChannel
structure when talking about it, and mention the default value of
"close on unref" in g_io_channel_unix_new().
https://bugzilla.gnome.org/show_bug.cgi?id=787123
Valgrind will check that the third argument to ioctl() is a valid
pointer, but some ioctls interpret that argument as an integer, and that
is the case here (it's a file descriptor), so this is a false positive.
https://bugzilla.gnome.org/show_bug.cgi?id=787109
