Originally, the standard idiom with GSimpleAsyncResult was to handle
all errors in the _finish wrapper function, so that vmethods only had
to deal with successful results. But this means that chaining up to a
parent _finish vmethod won't work correctly. Fix this by also checking
for errors in all the relevant vmethods. (We have to redundantly check
in both the vmethod and the wrapper to preserve compatibility.)
https://bugzilla.gnome.org/show_bug.cgi?id=667375https://bugzilla.gnome.org/show_bug.cgi?id=661767
The "mainloop_barrier" in copy_async_thread() is unnecessary, since
the g_simple_async_result_complete_in_idle() will be queued after all
of the g_io_scheduler_job_send_to_mainloop_async()s, and sources with
the same priority will run in the order in which they were queued.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
String validation was done by checking if the string was valid utf8 and
ensuring that the first non-utf8 character was the last character (ie:
the nul terminator).
No check was actually done to make sure that this byte actually
contained a nul, however, so it was possible that you could have a
string like "hello\xff" with length 6 that would correctly validate.
Fix that, and test it.
* Document how to override interfaces already implemented
in a base class, and also call those base class implementations
from a derived reimplementation.
* Don't recomend people use base_init() style functions to
initialize interface signals and properties, use default_init()
aka class_init() instead (as G_DEFINE_INTERFACE() uses).
* The above solves the interface init called multiple times
problem, so remove some needless naysaying about that.
* Document default_init() in the interface initialization discussion
* Linkify more stuff.
* Remove some crud and typos
https://bugzilla.gnome.org/show_bug.cgi?id=675504
The in commit b79fbc5c3f for fixing
-Wstrict-aliasing warnings was a little too brutal, make it a bit
better.
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
Prevent attempts to access keys ending with slashes that exist in the
schema file as references to child schemas.
Also: don't emit change signals for these same keys.
If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined
to a future value, we were essentially treating it as
GLIB_VERSION_0_0. Fix to treat it as being in the future instead.
https://bugzilla.gnome.org/show_bug.cgi?id=674898
The docs for GString should really mention GByteArray, and what makes
it different. Drop the comparison to Java which is dated and actually
inaccurate (because StringBuffer operates on Unicode).
While we're here, add g_string_free_to_bytes(), which further
complements the spread of GBytes-based API. For example, one can
create a buffer using GString, then send it off via
g_output_stream_write_bytes().
https://bugzilla.gnome.org/show_bug.cgi?id=677064
For a D-Bus property with name "Type" (fairly common), we used to
generate a GObject property with name "type-" and C accessors
get_type_() (to avoid clashing with the GType getter), set_type_()
(for symmetri).
However, the rules for GObject property names are fairly rigid and
specifically prohibit names ending in a dash.
Therefore change things so the chosen GObject property name is "type"
but preserve the naming rules for the C getter and setter (for the
same reasons: avoiding name clashing and symmetri).
This change does break the API of generated code (but only on the
GObject property level, the C symbols are not changed) but strictly
speaking the behavior was undefined since "type-" was an invalid
GObject property name.
Also add a test case for this.
Bug 679473.
https://bugzilla.gnome.org/show_bug.cgi?id=679473
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
This avoids warnings when creating idiomatic value tables, like:
static const GTypeValueTable _clutter_shader_float_value_table = {
clutter_value_init_shader_float,
clutter_value_free_shader_float,
clutter_value_copy_shader_float,
clutter_value_peek_pointer,
"ip",
clutter_value_collect_shader_float,
"pp",
clutter_value_lcopy_shader_float
};
Because the strings are literals. And, really: nobody should be using
allocated values for the collection and lcopy strings.
https://bugzilla.gnome.org/show_bug.cgi?id=671545
The Since tag for these was saying 2.28 but it was actually added in
2.31. It looks like all of the Since tags list stable version numbers
so this patch bumps that up to 2.32.
https://bugzilla.gnome.org/show_bug.cgi?id=679258
Since PCRE 8.00 it supports a variant of PCRE_NOTEMPTY that works
similarly except that it only applies to the start of the matched string
but permits empty matches further in.
g_regex_get_compile_get_compile_flags() and g_regex_get_match_flags()
were leaking PCRE flags that don't exist in the corresponding
public GRegexCompileFlags and GRegexMatchFlags; this change masks
these internal flags.
These flags override the compile option at match time. They use PCRE_BSR_ANYCRLF
and PCRE_BSR_UNICODE, resp., which make \R match only CR, LF and CRLF, or any
Unicode newline character or character sequences, resp.
When using the system PCRE, and it was compiled with incompatible options,
the code was returning from inside a g_once_init_enter/leave block without
calling g_once_init_leave().
