Prevent the situation where errno is set by function A, then function B
is called (which is typically _(), but could be anything else) and it
overwrites errno, then errno is checked by the caller.
errno is a horrific API, and we need to be careful to save its value as
soon as a function call (which might set it) returns. i.e. Follow the
pattern:
int errsv, ret;
ret = some_call_which_might_set_errno ();
errsv = errno;
if (ret < 0)
puts (strerror (errsv));
This patch implements that pattern throughout GLib. There might be a few
places in the test code which still use errno directly. They should be
ported as necessary. It doesn’t modify all the call sites like this:
if (some_call_which_might_set_errno () && errno == ESOMETHING)
since the refactoring involved is probably more harmful than beneficial
there. It does, however, refactor other call sites regardless of whether
they were originally buggy.
https://bugzilla.gnome.org/show_bug.cgi?id=785577
The Meson build has fallen a bit behind the Autotools one, when it comes
to the internally built tools like glib-mkenums and glib-genmarshals.
We don't need to generate gmarshal.strings any more, and since the
glib-genmarshal tool is now written in Python it can also be used when
cross-compiling, and without indirection, just like we use glib-mkenums.
We can also coalesce various rules into a simple array iteration, with
minimal changes to glib-mkenums, thus making the build a bit more
resilient and without unnecessary duplication.
gen-casefold-txt.pl and gen-casemap-txt.pl are licensed under GPLv2+, so
they are not touched by this commit.
A lot of *.c files in tests/ don't have a license header.
https://bugzilla.gnome.org/show_bug.cgi?id=776504
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
Signed integer overflow is undefined behaviour: if a compiler
detects signed integer overflow, it is free to compile it to absolutely
anything.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
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
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The test is to remove all the odd values with my_hash_callback_remove(),
then iterate over all values and verify that they are even. However,
failing this check would just print "bad!" instead of failing the test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
gdb is run in batch mode, and can leave leave the program being
executed/debugged running when the batchfile is finished. Explicitly
"quit"ing the subprocess prevents it from leaving the stray subprocess
when gdb finishes.
https://bugzilla.gnome.org/show_bug.cgi?id=731366
It turns out that due to a recent gdm change, the inherited
signal mask has SIGUSR1 blocked - which is bad news for
tests using SIGUSR1. Fix the test by explicitly checking the
signal mask before using SIGUSR1.
The mapping-test is failing under gnome-continuous. I suspect this
is simply due to running many tests in parallel, and mapping-test
being racy. Replace the blind sleep by signals, to avoid the
races.
g_time_val_from_iso8601 was attempting to parse strings
having only a date, but failed to actually set the timeval
despite returning TRUE. Since the docs state that the function
only parses strings containing a date and a time, just return
FALSE in this case.
Also remove an incomplete testcase for this behaviour that was
just checking the boolean return value, but not timeval.
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
...and only include unistd.h when we are on *NIX.
Newer Visual C++ runtimes (8.0/2005 and later) will cause the program to
crash with an internal abort() call when they detect instances of close()
being called on an invalid fd, such as when the fd is -1, and these should
be purged anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
