Clang static analyzer returned a false-positive issue in line 671:
The right operand of '<' is a garbage value
Variables needed to be moved up, because otherwise initialization
crosses to the next case.
Static analysis indicated an issue, when line was being passed as 2nd
argument to strcat:
Null pointer passed as an argument to a 'nonnull' parameter
Replace repeated strcat with creating a formatted string and use
the opportunity to do a small format cleanup.
- For each OS, builds of the default compiler plus the
latest-supported compilers are run. When multiple operating systems
are supported (such as Ubuntu 16.04 and latest), a build on
the oldest OS using its default compiler is also performed.
- Debug builds are used because they often are more thorough at
detecting coding issues (debug warning counts are higher).
- Runtime dynamic sanitizers are added and serialized per-compiler.
Their build and runtime log-files are xz-compressed, and then
GitHub's asset upload Zips the log directory.
- Each workflow now holds the maximum allowed compiler warnings
per-build, so we can have tighter control of when new warnings
are introduced (that would otherwise pass if still below the
maximum)
- Use of github's new 'cache' feature has been leveraged to restore
the brew, macports, and msys2 environments to eliminate the
lenghthy setup times for those environments. If a new cache
is needed, then we simply increment the cache `key:` value and
the next CI run will archive new caches. (Note that GitHub has a
400MB limit on cache size however they have already said they
are raising it - so we might be able to cache out longest running
job which is MSYS+Clang)
- Where it makes sense, multi-line workflow statements have been
broken out into .github/scripts as files to make the workflow YAML
leaner and more readable, while giving us a richer environment in
the scripts.
Until now the build and package scripts have supported
several architectures, compilers, build types, package-managers,
and bit-depth targets.
The code might be maintainable if left as-such, however we have plans
to continue expanding the number of architectures (ARM, PPC, ... ),
operating systems (Android, BSDs, ...), and build variations
amung those.
The scripts (regardless of language) would only grow in complexity
as more variations are added. Thus, we needed a solution that can
scale without adding complexity.
To achieve this, the scripts were refactored as follows:
- all "data" was moved out of code into configuration files
- A back-end "Automator" engine was written to parse the
data based on generic variables fed to it by a front-end
script
- build.sh and list-packages.sh were re-authored as thin front-end
scripts that drive the automator
- Their CLI's were retained so there has been very little change
needed to the CI invocation lines. The only changes have been to
clarify the existing arguments improved based on feedback, ie:
--build-type release, --build-type debug instead of fast, small
This change allows the maximum issues to be passed in as an argument.
If nothing is passed, then the existing build-in maximum is
used.
Retaining the existing built-in value makes sense for home
users to keep track of their local build (otherwise they would have
to remember the prior number of warnings and pass that value
in for subsequent builds).
Motivation: until now the built-in maximum covers the build permutation
that happens to generate the most warnings versus other builds.
In some cases new warnings may not be cause if they elicit a warning
from the lesser-warning build(s) or compilers, but not in the
maximum-warning build.
This change lets us tighten-down the warning uniquely for each build,
so we can be sure all new warnings are flagged to the developer.
Some distributions provide python2 version of pylint package by default,
but all provide pylint for python3 in some package. Python 2 reaches
EOL in few months, so there's no reason to support it.
This prevents our scripts from being accidentally marked invalid due to
language changes between python 2 and 3. Also, newer pylint has nicer
output, that provides exact module filename straight in the warning.
These files assume, that WIN32 is defined by compiler or MSVC project
file, when in MSYS2 and MinGW environments, it is defined in config.h
and appears after dosbox.h is included, which in turn is included by
associated header (cdrom.h in this case).
Fixes: #42
Includes two small scripts: verify-bash.sh for running shellcheck, and
verify-python.sh for running pylint.
.pylint rc files is a default configuration file generated by
pylint 2.3.1, with one change (min-similarity-lines changed
from 4 to 10).
Use C++11 static_assert to assure, that code behaves correctly; if
Chip or Channel structs will be changed to non-std layout or a different
first fields will be introduced, that will invalidate the offset
calculation.
Additionally, add asserts to prevent possibility of introducing a bug
when offset stored in one the tables is 0.
Silence compiler warnings:
enumeration value 'sm2Percussion' not handled in switch [-Wswitch]
enumeration value 'sm3Percussion' not handled in switch [-Wswitch]
Otherwise compilation fails on GCC 5.4 in Steam Runtime environment.
As of 2019, all up-to-date compilers support C++11, most of them
use C++14 as default standard, but C++14 is not fully supported by
autoconf in Ubuntu 16.04 LTS.
Full C++11 support was introduced in GCC 4.8.1 and Clang 3.3.
GitHub notified me, that they are dropping macOS-10.14 completely, all
users are upgraded to macOS-10.15 and the only valid value in CI jobs
will be macos-latest from now on.
I haven't seen any indication of the same happening for Windows
machines, but GitHub Actions documentation dropped all references to
windows-2016 and windows-2019 - windows-latest seems to be the only
valid value for shared runners from now on.
Ubuntu machines are left as they are (thankfully).
