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
This adds a common autotools module that can be used by various
projects to generate the Visual Studio projects as needed, and
if necessary, generate the headers listings to "install" for that
project, based on items passed in to this. This is modelled on the
Makefile.introspection autotools file that is used by many GNOME
projects to generate the introspection files.
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
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
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
GListStore already has a g_list_store_insert_sorted function,
which can be used to keep the list sorted according to a fixed
sort function. But if the sort function changes (as e.g. with
sort columns in a list UI), the entire list needs to be
resorted. In that case, you want g_list_store_sort().
https://bugzilla.gnome.org/show_bug.cgi?id=754152
Enhance GTestTlsBackend to allow setting the issuer property of
GTlsCertificates, and add a test to ensure certificate chain
construction with g_tls_certificate_new_from_pem() works as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
If a private key (or anything, in fact) follows the final certificate in
the file, certificate parsing will be aborted and only the first
certificate in the chain will be returned, with the private key not set.
Be tolerant of this, rather than expecting the final character in the
file to be the newline following the last certificate.
https://bugzilla.gnome.org/show_bug.cgi?id=754264
If @error is NULL then we don't even need to evaluate the remaining
arguments. And if errno is EWOULDBLOCK, then no one should see the
error message anyway, so don't bother g_strdup_printf'ing up a pretty
one.
https://bugzilla.gnome.org/show_bug.cgi?id=752769
