dukelow@noscvax.UUCP (03/12/84)
Since submiting an message concerning a bug in the IBM PC version of
Turbo Pascal I have received several comments. I guess trying to keep
a message short doesn't pay off since it just leads to having to write
another.
The bug (as previously reported):
const
m = 5; {arbitrary example}
type
s = array[1..m] of char;
var
a: array[1..n] of s;
.
.
a[1] := '12345'; {a random example}
writeln(a[1]); {results in garbage}
Response comments I have received:
1. Yes, I know that "s" should have been declared as a PACKED array. It
was in the original program where I discovered the bug. According to
the manual, PACKED is ignored by Turbo Pascal and, in fact, it makes
no difference in this case.
2. Even though, as one person pointed out, the above declaration of "a"
is equivalent to "a: array[1..n, 1..m] of char" there is nothing wrong
with the writeln statement above. It is not the same as trying "to print
out a two dimensional array using only one subscript". Again, the example
should have included PACKED for (ANSI/IEEE) standard Pascal, but it has
always been legal in Pascal to use elements of an array of any structure
anywhere that a simple variable of that structure is allowed. At any rate,
the bug I am trying to demonstrate has nothing to do with the writeln
statement. The error occurs in the assignment statement. The data in a[1]
is garbage. Note that the following works and is a way around the bug:
var
b: s;
.
.
b := '12345';
a[1] := b;
writeln(a[1]); {produces the correct result}
3. The error was discovered as I was porting a moderate sized program
from a much more standard compiler on another machine. This to me is
one of the most painful types of bugs since the symptoms can be very
obscure.
I repeat that I am generally very happy with Turbo Pascal. The program
I was porting when I discovered this bug is just over 3000 lines and
compiles in about 1.5 minutes (yes, I have been reading the articles
on measuring program size and complexity but don't have a better measure
handy). Overall, most of the problems I encountered had to do with
differnces between the UNIX environment the program was coming from and
the MS DOS target. The program was written to be used as a filter and
since Turbo uses old DOS calls for input and output it took some extra
effort to get the redirectable I/O working the way I wanted. When writing
a program specifically to be run under Turbo I have found many of the
extensions useful and well thought out (if not always well documented).
I would, however, echo a comment that someone else on the net has made.
Turbo tries to do a little too much for you. Having the program
automatically clear the screen and set the output character attributes
is cute but sometimes gets in the way.
As far as delivery, I got my copy in about 10 days after ording by phone
(using Master Card). If the rumors are true about delivery being delayed
because of a new release, I would like to hear what the changes are.
Questions that I have:
1. Has anybody heard what kind of update policy Borland has?
2. Is is possible to get an MS DOS version which will run on the PC
but produce more transportable code (i.e. do a little less for you)?
Sorry this got so long.
Bob Dukelow
dukelow@nosc