calc/BUGS

If you notice something wrong, strange or broken, try rereading:

   README.FIRST
   HOWTO.INSTALL
   BUGS (this file)

If that does not help, cd to the calc source directory and try:

   make check

Look at the end of the output, it should say something like:

    9998: passed all tests  /\../\
    9999: Ending regression tests

If it does not, then something is really broken!

If you made and modifications to calc beyond the simple Makefile
configuration, try backing them out and see if things get better.

To be sure that your version of calc is up to date, check out:

	http://www.isthe.com/chongo/tech/comp/calc/calc-download.html

The calc web site is located at:

	http://www.isthe.com/chongo/tech/comp/calc/index.html

=-=

If you have tried all of the above and things still are not right,
then it may be time to send in a bug report.  You can send bug
and bug fixes reports to:

    calc-bugs at asthe dot com

    [[ NOTE: Replace 'at' with @, 'dot' is with . and remove the spaces ]]
    [[ NOTE: The EMail address uses 'asthe', the web site URL uses 'isthe' ]]

Your subject must contain the words:

       calc bug report

You may have additional words in your subject line.

When you send your report, please include the following information:

    * a description of the problem
    * the version of calc you are using (if you cannot get calc
      to run, then send us the 4 #define lines from version.c)
    * if you modified calc from an official patch, send me the mods you made
    * the type of system you were using
    * the type of compiler you were using
    * any compiler warnings or errors that you saw
    * cd to the calc source directory, and type:

	make debug > debug.out 2>&1		(sh, ksh, bash users)
	make debug >& debug.out			(csh, tcsh users)

      and send the contents of the 'debug.out' file.

Stack traces from core dumps are useful to send as well.

Fell free to use the above address to send in big fixes (in the form
of a context diff patch).

=-=

Known bugs:

    We are sure some more bugs exist.  When you find them, please let
    us know!  See the above for details on how to report and were to
    EMail your bug reports and hopefully patches to fix them.

    * The following command:

	calc 'read ellip; efactor(13*17*19)'

      will generate the following error:

	efactor(iN,ia,B,force) defined
	point_print(p) defined
	point_mul(p1,p2) defined
	point_square(p) defined
	point_pow(p,pow) defined
	A = 1
	2 (1,1)
	"point_square": line 165: Not initializing matrix, object or list
	Error in commands

     This is not an error in the ellip standard calc resource files.
     It is a bug inside calc.  Versions going back as far as version
     2.11.4t2 in the year 2000 (and perhaps even further) all have
     this bug.

     Anyone want to track down and fix this bug?

=-=

mis-features in calc:

    Some problems are not bugs but rarther mis-features / things that could
    work better.  The following is a list of mis-features that should be
    addressed and improved someday.

    * The chi.cal resource file does not work well with odd degrees
      of freedom.  Can someone improve this algorithm?

    * The intfile.cal resource file reads and writes big or little Endian
      integers to/from files the hard way.  It does NOT use blkcpy.  The
      following code:

	i = (ord("\n") << 16) | (ord("i") << 8) | ord("H")
	b = blk()
	copy(i, b)
	fd = fopen("file", "w")
	copy(b, fd);
	fclose(fd)

      will write an extra NUL octet to the file.  Where as:

	read intfile
	i = (ord("\n") << 16) | (ord("i") << 8) | ord("H")
	be2file(i, "file2")

      will not.

=-=

Problems with old systems that have known work-a-rounds:

    * The gcc as shipped with Redhat 7 perhaps other Linux distributions
      has a bug causes calc to dump core on startup when calc is:

	  compiled optimized (-O, -O1, -O2 or -O3)

	  	AND

      	  compiled with debugging (-g or -g3)

	  	AND

	  when calc is compiled with readline (see USE_READLINE,
	  READLINE_LIB and READLINE_INCLUDE in the Makefile)

      This is known as the Redhat 7 readlne problem.

      On Redhat, the gcc -v which has this problem is:

	gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)

      there may be other gcc versions that also suffer this fate.

      The readlines associated with problem are:

	readline-4.1-5
	readline2.2.1-2.2.1-2
	readline-devel-4.1-5

      One work-a-round is to compile calc WITHOUT readline.  In the
      Makefile be sure that:

	USE_READLINE=
	READLINE_LIB=
	READLINE_INCLUDE=

      i.e., these Makefile vars are empty.

      If you must use readline, then an alternate work-a-round is to
      change the DEBUG Makefile variable to either:

	compile for speed:  -O3		(or -O2 if you do not have -O3)
	compile to debug:   -g3		(or -g if you do not have -g3)

      but not both.

      See RH bug #57889 for details:

	http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57889

    * There is a bug in gcc-2.95 that causes calc, when compiled with -O2,
      to fail the regression test.  The work-a-round is to compile with -O
      or to use gcc-2.96 or later.

      This bug has been observed on the Sparc and the PowerPC machine.

      On the PowerPC with gcc-2.95 when compiled with -O2, the following
      patch seems to help:

*** zfunc.c.orig        Fri Feb 23 18:18:39 2001
--- zfunc.c     Fri Feb 23 18:39:33 2001
***************
*** 1481,1487 ****
  {
        HALF *a, *A, *b, *a0, u;
        int i, j, j1, j2, k, k1, m, m0, m1, n, n0, o;
!       FULL d, e, f, g, h, s, t, x, topbit;
        int remsign;
        BOOL up, onebit;
        ZVALUE sqrt;
--- 1481,1488 ----
  {
        HALF *a, *A, *b, *a0, u;
        int i, j, j1, j2, k, k1, m, m0, m1, n, n0, o;
!       volatile FULL d;
!       FULL e, f, g, h, s, t, x, topbit;
        int remsign;
        BOOL up, onebit;
        ZVALUE sqrt;
*** zmath.c	2000/06/07 14:02:13	29.2
--- zmath.c	2001/03/13 19:47:03
***************
*** 1608,1614 ****
  void
  zbitvalue(long n, ZVALUE *res)
  {
! 	ZVALUE z;

  	if (n < 0) n = 0;
  	z.sign = 0;
--- 1608,1614 ----
  void
  zbitvalue(long n, ZVALUE *res)
  {
! 	volatile ZVALUE z;

  	if (n < 0) n = 0;
  	z.sign = 0;

    * Solaris cc somtimes barfs while compiling zrand.c.  In particular, calc
      barfs on on the SVAL macro.  The work-a-round is to use the Solaric cc
      Makefile set sets -DFORCE_STDC.  I.e,:

	    CCWARN=
	    CCOPT= ${DEBUG} ${NO_SHARED}
	    CCMISC= -DFORCE_STDC
	    #
	    CFLAGS= ${CCWARN} ${CCOPT} ${CCMISC}
	    ICFLAGS= ${CCWARN} ${CCMISC}
	    #
	    LCFLAGS=
	    LDFLAGS= ${NO_SHARED} ${LD_NO_SHARED}
	    ILDFLAGS=
	    #
	    LCC= cc
	    CC= ${PURIFY} ${LCC}

    * There is a bug in some versions of the Dec/Compaq cc for the Alpha
      where the following:

	    #include <stdio.h>
	    #define SVAL(a,b) (unsigned long)(0x ## a ## b ## ULL)
	    main(){SVAL(b8a8aeb0,8168eadc);}

      fails because it puts a space inside the concatenated hex.  Calc
      has code that is affected by this bug.  This bug has been reported
      to Compaq and may be fixed in the future.	 A work-a-round is to
      compile with cc -std0 or to use a later version of their compiler.

    * On a Digital UNIX V4.0F (Rev. 1229) on a 500 Mhz 21264, make check
      dies a horrible death starting in test 600 and 622 gives 100s of
      messages for calc version 2.11.0t9.4 using the Dec's cc with -O2:

	600: Beginning test_bignums
	601: muldivcheck 1
	**** abc != acb: 602: muldivcheck 2
	**** acb != bac: 602: muldivcheck 2
	...
	**** t4 != a4: 622: algcheck 1
	**** t5 != a5: 622: algcheck 1
	**** t6 != a6: 622: algcheck 1
	**** t4 != a4: 622: algcheck 1
	...

	it finally hangs at test 2000.

      The work-a-round is to compile calc without the optimizer.  If this
      happens to you, try compiling without -O and without -O2.	 I.e., in
      the Makefile, set:

	DEBUG= -g

    * There are problems compiling calc on the sparcv9 under 64 bit
      Solaris.	On that platform, gcc-2.96 is able to compile calc, but
      calc dumps core very early on in startup.	 It is said that sparcv9
      support in gcc-2.96 is very unofficial and thus there is no
      work-a-round for gcc-2-96.

      There is a work-a-round for this architecture us one is using the
      Solaris CC on the sparcv9.  It has been reported that setting the
      following Makefile variables will produce a working version of
      calc on the sparcv9 under 64 bit Solaris:

	    LCC="cc -xarch=v9"
	    CCWARN="-DFORCE_STDC -w"
	    DEBUG="-fast -xarch=v9"

    * Under BSDI v4, the warnings of the form:

	/usr/include/ctype.h:147: warning: `__runetype' defined but not used
	/usr/include/ctype.h:161: warning: `__isctype' defined but not used
	/usr/include/ctype.h:170: warning: `toupper' defined but not used
	/usr/include/ctype.h:177: warning: `tolower' defined but not used

      are seen.	 These warnings are the result of mis-features in BSDI
      include files.  They do not have an impact on the operation
      or performance.  The work-a-round is to ignore these warnings
      under BSDI.

## Copyright (C) 1999  Landon Curt Noll
##
## Calc is open software; you can redistribute it and/or modify it under
## the terms of the version 2.1 of the GNU Lesser General Public License
## as published by the Free Software Foundation.
##
## Calc is distributed in the hope that it will be useful, but WITHOUT
## ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
## or FITNESS FOR A PARTICULAR PURPOSE.	 See the GNU Lesser General
## Public License for more details.
##
## A copy of version 2.1 of the GNU Lesser General Public License is
## distributed with calc under the filename COPYING-LGPL.  You should have
## received a copy with calc; if not, write to Free Software Foundation, Inc.
## 59 Temple Place, Suite 330, Boston, MA  02111-1307, USA.
##
## @(#) $Revision: 29.22 $
## @(#) $Id: BUGS,v 29.22 2004/10/23 02:25:02 chongo Exp $
## @(#) $Source: /usr/local/src/cmd/calc/RCS/BUGS,v $
##
## Under source code control:	1994/03/18 14:06:13
## File existed as early as:	1994
##
## chongo <was here> /\oo/\	http://www.isthe.com/chongo/
## Share and enjoy!  :-)	http://www.isthe.com/chongo/tech/comp/calc/