The shelltest migration was done in 1.4, but not completed - the
distcheck was still doing hard-coded manual tests, and as such, the
"check" target from the dist archive was not working. Sigh.
Now 'distcheck' is using 'check', and the archive is complete.
I spent 20 minutes trying to understand why lcov/gcov were complaining
about wrong coverage format/version, before I saw I had a 2 year old
file that was not overwritten nor removed…
Switch to more recent versions of the checkout and codecov action, the
latter also removing saving the data locally, so remove the archival
of that data.
The embedding of tests in the Makefile works only for that is there
today - a few `--version` and `stinit -p` calls. For expanding the
test coverage, as much as it can be done for `mt`, let's use a proper
shell test runner. `shelltestrunner` is available in Debian/Ubuntu, so
it's likely to be available in other distributions too, and as such
should not be a big barrier to contribution.
This needs lcov installed, but it's a good quick helper for local
runs. For history and pull requests, codecov keeps tracking.
Also tweak in the process gitignore to clean the noise.
This is the exact same mini-"tests" that are used in distcheck, but
separated so that the tests can be run with coverage tracking. Would
be good not to have duplicates - maybe use make check inside the
distcheck?
While fixing #14, what pointed me to check parsing validity (and not
local issues as I thought at first) was that `-v -v` was showing empty
mode definitions, despite claiming parse success. So let's add a test
that mode parsing does do things, not just empty claims.
The GCC in xenial is old (5.x), and something seems to trip it
compared to the clang build, when checking the default options, see
https://travis-ci.org/iustin/mt-st/jobs/597087158.
Switch to bionic which has GCC 7, which is recent enough.
Left-shifting of negative values is undefined behaviour according to
the C standard, because it depends on the exact representation. This
code, copied from the Linux kernel, is intended for 2's complement and
can be replaced by well-defined behaviour: ~(-1<<N) is equivalent
to (1<<N)-1.
Signed-off-by: Iustin Pop <iustin@k1024.org>
Right now stinit ignores leftover chars in strings such as '9a'; let's
make sure we don't miss these (at least the warning message might give
a hint)..
Commit b48a427 removed the actual kernel version checks, but forgot
the calls to populate the values themselves. Remove them as we don't
do anything with those values.
The source code seems to have, over time, become less self-consistent
in style. In order to not have to keep this up manually, switch over
indenting to clang-format. A .clang-format file is provided to give
repeatable results.
The main difference is switching from tabs to non-tabs
usage. Otherwise the changes are mostly minor and leading to more
consistency. Contributions to the format style welcome!
Nota bene: this should have had no code impact. Any actual code
changes (beyond indenting) are bugs in the re-indent process.
There are three "tables" with structure initialization lists in mt.c,
which look like they were intended to be nicely-aligned, but over time
they got out of alignment.
Redo the alignment by unwrapping the lines and using Emacs'
align-regex, even though this leads to an exception of ~130 line
length for the 'cmds' table, since it leads to a very readable table
(on large terminals). Also protect these regions from clang-format, in
preparation for full file re-indents.
I can't find any mention of looking up stinit.def in the current
directory first, at least not since version 0.7. Correct the man page
to mention only `/etc/stinit.def'.
Instead of assuming all passed buffers are DEFMAX, use the given
buflen. Also change some types (int→size_t) since these are all
related to string sizes.
There is a long-standing (it was already present in 0.7, so around 15
years) bug in stinit's find_pars function, related to parsing per-mode
configurations. Due to the way the temporary buffers are used, at one
point a strcat() is called on overlapping strings. This is documented
not to work, but it seems the behaviour is not deterministic: for some
pairs of strings it works, for some not (possibly related to distance
between strings, etc.). This results in the fact that parsing the
provided example file fails for _some_ entries, but not for all, with
a seemingly wrong error message (showing snippets of the input file
that do not exist).
Fix this issue in a trivial way by simply using a different (new)
buffer during the mode parsing.
Iustin Pop
Chris Dinneen
kishorkunal-rajandIustin Pop
Paweł MarciniakandIustin Pop
Dan HorákandIustin Pop
Gris GeandIustin Pop
hrchuandIustin Pop