From phil@cs.wwu.edu Mon Mar 20 23:13:22 1995 Date: Mon, 20 Mar 1995 23:12:17 -0800 From: Phil Nelson 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 ; - * therefore we want 68 numerals, , - */ - 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