It seems like GitHub badges have some caching issues and they do not
work correctly (I have them showing two contradictory statuses,
depending on tab, no matter if I reload page or not).
This badge is useful link straight to the Coverity report, but Coverity
decides to present the scan results in quite misleading way - mixing
runs from master with runs from other branches.
It's better to show no info at all than to show misleading info.
Link to Coverity scan is accessible in README.md, as a reference [3] in
the comparison table.
GCC helpfully indicates, that:
warning: this ‘if’ clause does not guard (…) this statement, but
the latter is misleadingly indented as if it were guarded by the ‘if’.
Also, improve readability while we're touching these lines.
Previous glyph (Five Spoked Asterisk) looks great on Linux, but as it
turns out seems to be broken everywhere else. Use this opportunity to
point out, that SDL 1.2 in general is not being developed any more.
Also, make a correction:
"DOSBox does indicate support" -> "does not"
This bug was detected via Coverity static analysis:
Variable tempfile going out of scope leaks the storage it points to.
The leak happens when invalid keyboard layout file is being loaded:
$ touch xx.kl
$ dosbox .
C:\>keyb xx
Information in comparison table is based on developer testing on Linux
and user reports on Windows.
Remove VS-related info from INSTALL file instead of duplicating it in
README.md.
Details at: https://scan.coverity.com/dashboard
The Coverity software (Roughly 1.5GB worth unpacked from a tarball)
can only be downloaded from an authentication web sessions, so I've
uploaded it to my Google drive and use 'gdown' to pull it inside
the workflow. This sounds ugly, but it's not too bad: Coverity last
updated their software nine months ago, so this will be a once-a-year
change, maybe twice.
The Google drive ID, SHA256 checksum, and other specifics are all
variables at the top YAML, so they're easy to adjust when Coverity
makes their next update. The download, extraction, and sha256
verification are all done in parallel via pipes, and extracting to
/dev/shm. It should be pretty quick. Edit: it is; 4 seconds.
To keep the tarball small, I remove unecessary bits (but this is
optional), before tar & zstd compressing it:
``` bash
rm -rf closure-compiler jars jdk11 jre node support-angularjs
cd bin
rm *java* *js* *php* *python* *ruby*
```
This works out of the box on Linux and MSYS2, but does not work on
macOS - Xcode supplied make does not support this option, so GNU make is
used instead.
Unfortunately, adding new package on macOS did not invalidate the cache,
this package removes the brew cache from macOS job to avoid this problem
in the future.
Fixes: #53
Issue reported by Dagar and Pr3tty F1y, and confirmed as a bug by ripsaw8080.
Thank you!
This fixes the GoG release of Betrayal at Krondor which (either due to CD mastering
issues or a faulty rip), requests playback of a given track at the tail end
of the prior track.
In debugging and performing this fix, many debug messages were improved as well
as making some small small code adjustments, such as using iterators to point to
individual tracks (track->attribute) instead of using the tracks array
(tracks[track -1].attribute).
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.
