calcv3: planning, testing, where to go, what to eat, questions not leading to 42.

[SirWumpus]

@lcn2 recent update, I tested calcv3 on NetBSD and it now passes the current set of tests:

elf$ gmake chk
CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -d -q read regress 2>&1 | awk -f check.awk

chk OK
elf$

[lcn2]

@lcn2 recent update, I tested calcv3 on NetBSD and it now passes the current set of tests:

elf$ gmake chk

CALCPATH=./cal LD_LIBRARY_PATH=. DYLD_LIBRARY_PATH=. CALCHELP=./help CALCCUSTOMHELP=./custom ./calc -d -q read regress 2>&1 | awk -f check.awk



chk OK

elf$

Thank you very much, @SirWumpus for the good news, AND for previously reporting on a NetBSD issue. That issue was due to code that was put into calc long ago that, while it "sort of worked" on a number of things, did "digitally naughty" things to the internals of an opaque data type (i.e., fpos_t).

Now under calc v3, a lot of "code rot" was removed and calc no longer plays games with internals of opaque types. This is important because calc's numeric values "need to be" independent of both hardware and the OS. We say "need to be" rather than "must" because there are some hardware and OS environments that calc v3 won't support, such as:

• pdp Endian byte order (use either Big Endian or Little Endian order)
• 8-bit, 16-bit and 32-bit processors (use calc v2 for 32-bit)
• Windoz DLL import/export rot (use Cygwin or build calc as a static binary)
• UNIX v1 thru v7
• etc.

Nevertheless under a reasonable OS (and SUS-like is a good start), and 64-bit or larger CPUs, calc should produce the same numeric answers assuming you have the CPU time and memory to complete the calculations.

We have worked hard to minimize memory leaks, buffer overruns, memory smashes, use of un-initialized values in calc so that calculations that run for years (we are aware of a 12-year long run in one case).

One of our TODO next targets: remove code barriers that prevent calc from using numeric values that exceed 2^31 bytes. See the top level comment for more TODOI details.