path: root/contrib/bc/Test/TESTS.bc

From phil@cs.wwu.edu Mon Mar 20 23:13:22 1995
Date: Mon, 20 Mar 1995 23:12:17 -0800
From: Phil Nelson <phil@cs.wwu.edu>
To: phil@steelhead.cs.wwu.edu
Subject: [jhn@ironwood.cray.com: XPG4 bc(1) failures]

From: jhn@ironwood.cray.com (James Nordby)
Subject: XPG4 bc(1) failures
To: phil@cs.wwu.edu
Date: Fri, 17 Mar 1995 12:14:13 -0600 (CST)
X-Mailer: ELM [version 2.4 PL24-CRI-b]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 14277     


Phil,

Here are the test results I'm getting from the XPG4 test suite,
with some explanation and fixes so far.  Let me know what you
think...

Thanks much,
Jim Nordby (jhn@cray.com)


--------  bc			08:38:34  --------

Assertion #20 (A): bc reads text files
Expected exit code = 0; Received 139
Standard output isn't the same as file 'bc_eso_20_1'
diff of "out.stdout" and "bc_eso_20_1":
*** out.stdout	Fri Mar 17 08:39:22 1995
--- bc_eso_20_1	Fri Mar 17 08:39:22 1995
***************
*** 0 ****
--- 1,31 ----
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 11111111111111111111111111111111111111111111111111111111111111111111
+ 1111111
Assertion Result: FAIL

I couldn't reproduce this problem; when I rebuilt your bc and
ran it, I got a different problem with printing out a large
number.  The XPG4 tests expected lines to be 70 characters
long, INCLUDING the newline (this comes from the POSIX definition
of a line).  To fix it, I changed util.c like so:

*** util.c      Thu Mar 16 10:47:36 1995
--- util.c.old  Thu Mar 16 10:50:10 1995
***************
*** 309,323 ****
    else
      {
        out_col++;
- #ifdef _CRAY
-       /*
-        * XPG4 considers a line to include the <newline>;
-        * therefore we want 68 numerals, <backslash>, <newline>
-        */
-       if (out_col == 69)
- #else
        if (out_col == 70)
- #endif
        {
          putchar ('\\');
          putchar ('\n');
--- 309,315 ----






Assertion #42 (A): check reserved words
Standard error isn't empty
Contents of out.stderr:
(standard_in) 6: syntax error
(standard_in) 15: syntax error
Standard output isn't the same as file 'bc_eso_42_1'
diff of "out.stdout" and "bc_eso_42_1":
*** out.stdout	Fri Mar 17 08:39:43 1995
--- bc_eso_42_1	Fri Mar 17 08:39:43 1995
***************
*** 1,2 ****
--- 1,3 ----
  2
  1
+ 0
Assertion Result: FAIL

This one is debatable, based on the grammar in the POSIX manual.
Here's the input file:

cat << \VSC-EOF > input
define a() {
        auto b;
        for ( b = 0; b < 10; b++ ) {
                b;
                if ( b == 1 )
                        break;
        }
        return ( 5 ) ;
}
ibase = 10;
length ( obase );
scale = 0;
sqrt(1);
while ( a() != 5 )
VSC-EOF

They want these constructs to be accepted:


if (b == 1)
	whatever;
for (x = 0; x < 10; x++)
	whatever;
while (x < 10)
	whatever;

rather than just

if (b == 1) {
	whatever
}
etc.

The grammar as it's currently worded requires a '{' before hitting
a NEWLINE for these constructs.  It's easy enough to change in bc.y
(see below), but if I do change it, it still barfs on the last
line of the file ( 'while (a() != 5)' ).  Since the while lacks
a body, it gives a syntax error; they're expecting a '0' to be
returned.  The grammar could be changed to support this, but is
it a good idea?


*** bc.y	Thu Mar 16 10:47:20 1995
--- bc.y.old	Thu Mar 16 10:50:11 1995
***************
*** 142,150 ****
    			| error statement
  			    { $$ = $2; }
  			;
- allow_newlines		: /* empty */
- 			| NEWLINE allow_newlines
- 			;
  statement 		: Warranty
  			    { warranty (""); }
  			| Limits
--- 142,147 ----
***************
*** 231,237 ****
  				sprintf (genstr, "pJ%1d:N%1d:", $4, $7);
  			      generate (genstr);
  			    }
! 			  allow_newlines statement
  			    {
  			      sprintf (genstr, "J%1d:N%1d:",
  				       continue_label, break_label);
--- 228,234 ----
  				sprintf (genstr, "pJ%1d:N%1d:", $4, $7);
  			      generate (genstr);
  			    }
! 			  statement
  			    {
  			      sprintf (genstr, "J%1d:N%1d:",
  				       continue_label, break_label);
***************
*** 246,252 ****
  			      sprintf (genstr, "Z%1d:", if_label);
  			      generate (genstr);
  			    }
! 			  allow_newlines statement  opt_else
  			    {
  			      sprintf (genstr, "N%1d:", if_label); 
  			      generate (genstr);
--- 243,249 ----
  			      sprintf (genstr, "Z%1d:", if_label);
  			      generate (genstr);
  			    }
! 			  statement  opt_else
  			    {
  			      sprintf (genstr, "N%1d:", if_label); 
  			      generate (genstr);
***************
*** 265,271 ****
  			      sprintf (genstr, "Z%1d:", break_label);
  			      generate (genstr);
  			    }
! 			')' allow_newlines statement
  			    {
  			      sprintf (genstr, "J%1d:N%1d:", $1, break_label);
  			      generate (genstr);
--- 262,268 ----
  			      sprintf (genstr, "Z%1d:", break_label);
  			      generate (genstr);
  			    }
! 			')' statement
  			    {
  			      sprintf (genstr, "J%1d:N%1d:", $1, break_label);
  			      generate (genstr);




Assertion #49 (A): check strings
Expected exit code = 0; Received 1
Standard error isn't empty
Contents of out.stderr:
File (NULL) is unavailable.
Standard output isn't the same as file 'bc_eso_49_1'
diff of "out.stdout" and "bc_eso_49_1":
cmd-1794 diff: Missing newline at end of file 'bc_eso_49_1'.
*** out.stdout	Fri Mar 17 08:40:01 1995
--- bc_eso_49_1	Fri Mar 17 08:40:01 1995
***************
*** 0 ****
--- 1 ----
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
*LINE CONTINUATION -aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
*LINE CONTINUATION -aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Assertion Result: FAIL

This gist of this is that the standard expects numbers to
be truncated to 70 characters, but STRINGS should not.
My changes to fix this are:


*** execute.c	Thu Mar 16 13:06:39 1995
--- execute.c.old	Thu Mar 16 10:50:09 1995
***************
*** 208,218 ****
        case 'O' : /* Write a string to the output with processing. */
  	while ((ch = byte(&pc)) != '"')
  	  if (ch != '\\')
- #ifdef _CRAY
- 	    putchar (ch);
- #else
  	    out_char (ch);
- #endif
  	  else
  	    {
  	      ch = byte(&pc);
--- 207,213 ----
***************
*** 219,234 ****
  	      if (ch == '"') break;
  	      switch (ch)
  		{
- #ifdef _CRAY
- 		case 'a':  putchar (007); break;
- 		case 'b':  putchar ('\b'); break;
- 		case 'f':  putchar ('\f'); break;
- 		case 'n':  putchar ('\n'); break;
- 		case 'q':  putchar ('"'); break;
- 		case 'r':  putchar ('\r'); break;
- 		case 't':  putchar ('\t'); break;
- 		case '\\': putchar ('\\'); break;
- #else
  		case 'a':  out_char (007); break;
  		case 'b':  out_char ('\b'); break;
  		case 'f':  out_char ('\f'); break;
--- 214,219 ----
***************
*** 237,243 ****
  		case 'r':  out_char ('\r'); break;
  		case 't':  out_char ('\t'); break;
  		case '\\': out_char ('\\'); break;
- #endif
  		default:  break;
  		}
  	    }
--- 222,227 ----
***************
*** 350,360 ****
  	break;
  
        case 'w' : /* Write a string to the output. */
- #ifdef _CRAY
- 	while ((ch = byte(&pc)) != '"') putchar (ch);
- #else
  	while ((ch = byte(&pc)) != '"') out_char (ch);
- #endif
  	if (interactive) fflush (stdout);
  	break;
  		   



Assertion #77 (C): output longer than 70 characters
Standard output isn't the same as file 'bc_eso_77_1'
diff of "out.stdout" and "bc_eso_77_1":
*** out.stdout	Fri Mar 17 08:41:13 1995
--- bc_eso_77_1	Fri Mar 17 08:41:13 1995
***************
*** 1,2 ****
! 3.3333333333333333333333333333333333333333333333333333333333333333333
! 33333333333333333333333333333333
--- 1,2 ----
! 3.333333333333333333333333333333333333333333333333333333333333333333
! 333333333333333333333333333333333
Assertion Result: FAIL

Same as assertion #20 above...




Assertion #92 (A): check %
Standard output isn't the same as file 'bc_eso_92_1'
diff of "out.stdout" and "bc_eso_92_1":
*** out.stdout	Fri Mar 17 08:41:33 1995
--- bc_eso_92_1	Fri Mar 17 08:41:33 1995
***************
*** 4,8 ****
  4
  15
  1
! 0
! 0
--- 4,8 ----
  4
  15
  1
! 6
! 5
Assertion Result: FAIL

This one is a pain.  The failing code looks like this:

scale = 4
scale ( 5.000000 % 2.0 )
scale ( 5.00 % 2.0 )

They expect '6' and '5' for output, instead of '0', based on
the explanation of the modulus operator ("scale of the result
shall be 'max(scale + scale(b), scale(a)'"), even though the
result is a 0.  I was able to fix this problem by the change
below:

*** number.c    Thu Mar 16 13:15:43 1995
--- number.c.old        Thu Mar 16 10:50:09 1995
***************
*** 614,623 ****
        case  0:
          /* They are equal! return zero! */
          diff = copy_num (_zero_);   
- #ifdef _CRAY
-         /* correct the scale here */
-         diff->n_scale = MAX (n1->n_scale, n2->n_scale);
- #endif
          break;
        case  1:
          /* n2 is less than n1, subtract n2 from n1. */

but this causes another test failure that I haven't looked at.




Assertion #130 (A): functions are call by value
Standard output isn't the same as file 'bc_eso_130_1'
diff of "out.stdout" and "bc_eso_130_1":
*** out.stdout	Fri Mar 17 08:42:24 1995
--- bc_eso_130_1	Fri Mar 17 08:42:24 1995
***************
*** 4,10 ****
  5
  4
  0
! 4
  3
  3
  5
--- 4,10 ----
  5
  4
  0
! 5
  3
  3
  5
Assertion Result: FAIL

Assertion #131 (A): functions are call by value
Standard output isn't the same as file 'bc_eso_131_1'
diff of "out.stdout" and "bc_eso_131_1":
*** out.stdout	Fri Mar 17 08:42:28 1995
--- bc_eso_131_1	Fri Mar 17 08:42:28 1995
***************
*** 4,10 ****
  5
  4
  0
! 4
  3
  3
  5
--- 4,10 ----
  5
  4
  0
! 5
  3
  3
  5
Assertion Result: FAIL


Both of these are the 'arrays are passed by value' problem.
One of the test cases is below:

cat << \VSC-EOF > bc_in_130_1
a[0] = 3
a[0]
define b(a[]) {
a[0]
a[0] = 4
a[0]
}
a[0]
a[0] = 5
a[0]
b(a[])
a[0]
VSC-EOF

They expect the assignment of a[0] inside the b() function
to not affect a[0] outside of the function.





Assertion #139 (A): check sin
Standard output isn't the same as file 'bc_eso_139_1'
diff of "out.stdout" and "bc_eso_139_1":
*** out.stdout	Fri Mar 17 08:42:40 1995
--- bc_eso_139_1	Fri Mar 17 08:42:39 1995
***************
*** 1,5 ****
  0
! 20
  1.68294196961579301330
  20
  1.6829419696
--- 1,5 ----
  0
! 0
  1.68294196961579301330
  20
  1.6829419696
Assertion Result: FAIL

Assertion #141 (A): check arctanngent
Standard output isn't the same as file 'bc_eso_141_1'
diff of "out.stdout" and "bc_eso_141_1":
*** out.stdout	Fri Mar 17 08:42:44 1995
--- bc_eso_141_1	Fri Mar 17 08:42:44 1995
***************
*** 1,5 ****
  0
! 20
  3.14159265358979323844
  20
  3.1415926532
--- 1,5 ----
  0
! 0
  3.14159265358979323844
  20
  3.1415926532
Assertion Result: FAIL

Assertion #142 (A): check log
Standard output isn't the same as file 'bc_eso_142_1'
diff of "out.stdout" and "bc_eso_142_1":
*** out.stdout	Fri Mar 17 08:42:47 1995
--- bc_eso_142_1	Fri Mar 17 08:42:47 1995
***************
*** 1,5 ****
  0
! 20
  2.30258509299404568401
  20
  2.3025850929
--- 1,5 ----
  0
! 0
  2.30258509299404568401
  20
  2.3025850929
Assertion Result: FAIL

Assertion #144 (A): check bessel
Standard output isn't the same as file 'bc_eso_144_1'
diff of "out.stdout" and "bc_eso_144_1":
*** out.stdout	Fri Mar 17 08:42:51 1995
--- bc_eso_144_1	Fri Mar 17 08:42:51 1995
***************
*** 1,5 ****
  0
! 20
  .57672480775687338720
  20
  .5767248077
--- 1,5 ----
  0
! 0
  .57672480775687338720
  20
  .5767248077
Assertion Result: FAIL

All of these are the same.  I'll give you the test case
for 'sin'; what they're expecting is 0:

scale(s(0))

bc outputs '20' (which is the scale at the time), but the
interpretation of the standard says that it should be '0',
since s(0) is 0, and the scale of 0 is 0.  I think that
this interpretation disagrees with one of the previous
assertions (assertion #92).

/* end of test results */



-- 
Phil Nelson
e-mail: phil@cs.wwu.edu
http://www.cs.wwu.edu/~phil