Despite knowing about GError, there are multiple cases where developers
have still used traditional numeric error codes, and then got themselves
into a mess about bindability and generation of error messages.
Try and avoid this by including a brief paragraph on the benefits of
GError over EINVAL-style error codes.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This means that the top of the documentation can link forward to this
important section, and random people on the internet can link directly
to it on developer.gnome.org.
https://bugzilla.gnome.org/show_bug.cgi?id=743011
This reverts commit 662bf991c0. It is not
a straight up revert because the old commit involved various long since
removed ChangeLog files and we'd end up mudding the patch.
The system_header GCC pragma is breaking warnings in the various
g_return_* macros; GCC stopped warning when using a macro with a return
value in a function that returns void, as well as when using a macro
with no return value in a function that has a non-void return value.
Suppressing this kind of warnings is not a good idea.
Other compilers are unaffected, even ones like Clang with a GCC
compatibility layer.
Given the fact that the original commit was added 14 years ago as a
workaround in the old days of GTK+ 1.2, I think it's safe to drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=753310
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
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
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
Windows does not have strerror_r(), but does have strerror_s(), which is
threadsafe, and does more or less the same thing, so use it on Windows to
fix the build.
https://bugzilla.gnome.org/show_bug.cgi?id=754431
In the same way that gtestutils used to let you create multiple suites
with the same name, it also let you create multiple tests with the
same name. Make that an error instead (and fix glib/tests/base64.c,
which was registering three separate tests named
"/base64/incremental/nobreak/4", and glib/tests/autoptr.c, which was
running test_g_variant_builder() twice).
https://bugzilla.gnome.org/show_bug.cgi?id=754286
In non-TAP mode, tests that used g_test_skip() were labelled "OK", and
tests that used g_test_incomplete() were labelled "FAIL". Explicitly
show them as "SKIP" and "TODO" instead, like in the TAP case.
Also, incomplete/TODO tests are not supposed to be treated as
failures, so fix that too.
https://bugzilla.gnome.org/show_bug.cgi?id=754286
TAP allows you to print the "test plan" (ie, the expected number of
tests" either at the start or the end of the test program, but if you
put it at the end, and the program crashes, automake will complain
"missing test plan", which is confusing to users (particularly since
it prints that *before* it prints that the test program crashed,
suggesting that somehow the lack of test plan was responsible for the
crash or something, rather than vice versa).
Anyway, change it to count the tests ahead of time, and print the test
plan first. Keeping this simple requires disallowing the '-p', '-s',
and '--GTestSkipCount' options when using '--tap' (although we were
already printing the wrong number in the --GTestSkipCount case
anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=754284
Rewrite g_test_suite_run() and g_test_suite_run_internal() to make it
clearer what they do (while still preserving exact backward
compatibility, meaning we need to handle the "-p" case differently
from the non-"-p" case).
https://bugzilla.gnome.org/show_bug.cgi?id=754284
It seems to be common for people to use g_warning() or g_error() as pre-
and post-condition error reporting functions, which is not really what
they’re intended for. Similarly, it is generally a sign of bad API
design to use g_warning() to report errors — use GError instead.
Try and suggest this to the user in the hope that nice code results.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
It’s very common to see code where a timeout is scheduled using
g_timeout_add(), yet the owning object could be destroyed shortly
afterwards, before the timeout is fired, leading to use-after-free.
Try and prevent this happening with new code by documenting best
practices for memory management of user data for GSource callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
