d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a078a05252
freebsd-skq/contrib/bc/Test/TESTS.bc
Andreas Klemm 17f33912d7 Import GNU bc 1.04 
PR:		4183
1998-04-29 21:53:01 +00:00

566 lines
14 KiB
Plaintext
Raw Blame History

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
Reference in New Issue View Git Blame Copy Permalink