Re: gnucap save prompt error

On Thu, 27 Aug 2020 10:34:06 +0200
Felix Salfelder <[email protected]> wrote:
> Al has fixed it here [1]. will hopefully show up in develop soon.


I commented out the assert.  It isn't necessary.

A commented out assert means "You might expect this to be true, and it
probably usually is, but don't count on it.  There are known cases
where it isn't."


This and another fix are in the branch bug/segv . 
If there are no objections, this will be merged to develop soon.

The other fixes a bug introduced in the 20200806 merge. ..
which is a misuse of "prechecked_cast".


a note on the builds ...

The makefile's are set up for either a "release" or "debug" build.

The release build (plain "make") turns off debugging code, uses high
optimization, minimally verbose compiling, etc ..  It is intended to be
the usual way that users will build it for real use, without
distractions.

The debug build ("make debug") is intended for those working on the
code (that's us!).  Detailed warnings, enables extra code to check
correctness (asserts, etc).  This includes array bounds checking on
every access, validating invariants, and more.  "-O0" (optimization
zero) means no optimization at all, so debug tracing makes sense.  All
function calls, even trivial ones, are real function calls, with full
stack frame and overflow checking.  It's bigger and runs a lot slower!

To give you an idea of how much overhead this is .. consider a single
array access in m_matrix.  It is designed to be fast, so solving is a
set of vector operations, and a single access is as fast as a single
dense access ..  a[i][j].   In the release build, this is inlined and
there is no bounds checking.  In the debug version, both i and j are
checked to be in bounds, which is not just a check of the limits, but
also a check that this spot in the matrix was actually allocated, and
it's a real function call.  With anything less, we wouldn't really know
if it actually works as intended.

Both ways of building should give identical results, except for a big
linear difference in speed.  Usually, non-identical results indicate
errors, but occasionally a one-bit difference in a floating point
calculation might show, and demand attention.  The test scripts
intentionally do not hide these differences.  Some are designed to
expose these sensitive spots.