[net.micro] Turbo Pascal bug

dukelow@noscvax.UUCP (03/06/84)

I sent the following bug report to Borland International last week. I will post
another article if and when I get a response. The following program produces
incorrect results for the MS DOS version of Turbo Pascal for the IBM PC. I have
no idea whether it works for other versions and have not tried to further
generalize the nature of the bug.

I am generally very impressed with Turbo Pascal and hope that Borland is
pricing it at a level which will allow them to continue to improve the product.
It is too good to just let sit.

The values for the constants or whether the program is run from memory or
COM file seem to make no difference (except for the value of the resulting
garbage).

					Bob Dukelow
					(dukelow@nosc)

program bugtest;
  const
    m = 5; {arbitrary as far as I know}
    n = 5; {also arbitrary}
  type
    s = array [1..m] of char;
  var
    a: array[1..n] of s;
    b: s;

  begin
  a[1] := '12345';
  writeln('the following is garbage: ', a[1]);
  b := '12345';
  a[1] := b;
  writeln('the following seems to be ok: ', a[1]);
  writeln('type CR to continue');
  readln;
  end.

timborn@ihuxv.UUCP (-) (03/08/84)

	.
	.
	.
type 	
	s = array[1..n] of char;
var
	a : array[1..m] of s;
	.
	.
	.
writeln('This is garbage ',a[1]);

=======
Why is it surprising to get garbage when you try to print out a two dimensioned
array using only one subscript?  The surprising thing to me is that the 
compiler let you get that far.  Array a is equivalent to
var a : array[1..m,1..n] of char;

tdb

young%uci-750a@sri-unix.UUCP (03/14/84)

From:  Michal Young <young@uci-750a>


In response to the person who thought the reported bug was wrong, 
because it uses an assignment to a singly subscripted component of
a doubly subscripted array (i.e. an array of arrays of char):

Wrongo!  A quoted string is the same as a packed array of char in Jensen
& Wirth standard Pascal, so assigning a quoted string to one component
of an array, each component of which is an array of characters, is 
perfectly legal and reasonable.  If Turbo doesn't do it right, it's 
a bug.

--Michal Young

ags@pucc-i (Seaman) (03/22/84)

>  In response to the person who thought the reported bug was wrong, 
>  because it uses an assignment to a singly subscripted component of
>  a doubly subscripted array (i.e. an array of arrays of char):
>  
>  Wrongo!  A quoted string is the same as a packed array of char in Jensen
>  & Wirth standard Pascal, so assigning a quoted string to one component
>  of an array, each component of which is an array of characters, is 
>  perfectly legal and reasonable.  If Turbo doesn't do it right, it's 
>  a bug.

In J&W Pascal, there is a world of difference between an "array of char"
and a "packed array of char".  In particular, string assignments are
supposed to be legal ONLY with PACKED arrays, and ONLY if the lower bound
is 1.

Therefore the example that was posted earlier was not legal J&W Pascal, 
since it involved assigning a character string to an [unpacked] array of 
char.  I am not familiar with Turbo Pascal.  It could be that the distinction
is ignored in that implementation.
-- 

Dave Seaman
..!pur-ee!pucc-i:ags

"Against people who give vent to their loquacity 
by extraneous bombastic circumlocution."

cbk@se-sd.UUCP (cbk) (01/28/86)

[ dang fool superstitious programmers... ]

   I have noticed a problem (?) with running larger Turbo Pascal programs
(and indeed, Turbo itself).  When the program terminates, the A: drive is
*always* searched to load COMMAND.COM.  Note that this occurs regardless of
the setting of the COMSPEC environment variable.  This is somewhat annoying,
as I have a hard disk with COMMAND.COM stuck in C:\BIN, and it would be nice
to go there instead of searching on A:.  This happens on both 2.0 and 2.11 
versions of DOS.  There is nothing in the Turbo manual about this, and
according to the DOS manual, the COMSPEC path is searched to re-load
COMMAND.COM.  Any suggestions, fellow DOS hackers?  As usual, *mail* any/all
replies to me, results will be summarized in net.micro.  Thanks in advance!

==========
Carl Kuck      UseNet (West) : {wherever}!sdcsvax!ncr-sd!se-sd!cbk
                      (East) : {wherever}!ihnp4!ncr-sd!se-sd!cbk
               PacBell: (619) 450-6271 (w) 
                              944-1705 (h)

Quote #1: Only those who attempt the absurd can achieve the impossible.
Quote #2: 55 mph isn't a good idea, it's just the law...