Keeping these enabled causes too many people to file
bugs against gobject, and not enough people to send
patches to port away from deprecated properties.
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.
I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=754986
For all test cases where the text length is given as -1, also
call g_utf8_validate() with the actual string length to exercise
the known-length case. Unknown-length and known-length validation
use different code paths, but most of the tests only exercised with
unknown-length parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=754924
A recent change permitted some characters from range 0x80-0xbf as
would-be valid sequence starters for length 2, as long as
continuation characters were OK.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
This code is used in the property notification path, so it
better be fast. This commit removes a g_return_if_fail check and
treats the common case of just a single data element better.
Apply the same optimization that was done for g_unichar_get_script
long ago: Use a quick check for the low end, and then remember the
midpoint of the last bsearch, since we're likely to be called for
characters that are close to each other.
This change made g_unichar_iswide disappear from profiles of the
gtk3-demo listbox example.
Store the (translated, UTF-8-encoded) error strings in a hash table to
avoid doing translation and (possibly) g_locale_to_utf8() in every
g_strerror() call.
https://bugzilla.gnome.org/show_bug.cgi?id=754788
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
This "adds" the Visual Studio 2015 Project files by doing what we did
before: copying the Visual Studio 2010 projects and replacing items
in them, as the formats of the Visual Studio 201x projects are largely
the same.
Use a simple all-purpose utility script to generate the glib-mkenums
PERL script with the version info, and stop using the script that
tries to parse the autotools files. Move the things that
were taken out from build/win32/setup.py back there.
Update the autotools module so that we can use it to upgrade the
Visual Studio 2010 projects to become Visual Studio 2015-compatible.
Note that this will make the MSVC 2015 builds use the the the latest
VC140 CRT.
Many of the append and prepend variants are just thin wrappers
around another one. Remove parameter checking in the wrapper
for these cases. The wrapped function is checking them anyway.
Unrolling the branches and expressions for all expected cases
of UTF-8 sequences facilitates the work of both an optimizing compiler
and the branch prediction logic in the CPU. This speeds up decoding
noticeably on text composed primarily of longer sequences.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
The number of branches and logical operations can be reduced by
never producing a resulting wide character value to check its range.
Instead, individual bytes in the sequence are validated
depending on the branch taken on the basis of preceding bytes.
The syntax given in RFC 3629 is made use of.
https://bugzilla.gnome.org/show_bug.cgi?id=738504
