The following messages have been extracted from the MIX PASCAL Conference.
They represent a discussion of the Turbo PASCAL FillChar Function and
would probably be of interest to those learning Turbo PASCAL.
Some of the messages have been slightly edited to improve clarity and
to control the size of the compilation!

Msg # 161 Dated 03-15-87
From: BILL FOWLER
To: ALL
I've run into a glitch in Turbo PASCAL that I can't seem to fathom.
Can anyone tell me why the following code - - -
PROGRAM FillChar;
VAR
Dashes : String[20];
BEGIN
FillChar(Dashes,SizeOf(Dashes),'-');
Writeln(Dashes);
Writeln('The length of Dashes is ',Length(Dashes));
Writeln('The Size of Dashes is ',SizeOf(Dashes));
END.
Gives me this result?
Running
--------------------{ 25 NON-ASCII CHARACTERS FOLLOW THE DASH LINE}
The length of Dashes is 45
The Size of Dashes is 21
Where did the 25 non-ASCII characters come from and how did the Dashes
variable suddenly become 45 in length?

Msg # 163 Dated 03-16-87
From: BILL MAYNE
To: BILL FOWLER
FillChar takes no account of the type of variable being filled.
In Turbo Pascal the first byte of a string variable (e.g. Dashes[0])
is used to store a value indicating the length of the string. (That
is why the size is 21 even though the max length is 20 characters.)
Since you are putting a '-' dash in the first byte when you fill the
variable with '-'s, and '-' is ASCII 45, you have inadvertently
caused Turbo PASCAL to think the variable is 45 bytes long.
To fill a string you should use something like:
Dashes[0]:=Chr(SizeOf(Dashes)-1);
FillChar(Dashes,SizeOf(Dashes)-1,'-');

Msg # 165 Dated 03-17-87
From: BILL FOWLER
To: BILL MAYNE
Thanks for the response. You were on the right track. I played around
with changing the [0] byte of the string in order to control the
FillChar length. Your code was correct if I reversed the order of the lines,
i.e. fill the string first, then reset the [0] byte. The following
code..........
PROGRAM FillChar;
VAR
Dashes : String[20];
BEGIN
FillChar(Dashes,SizeOf(Dashes),'-');
Dashes[0] := Chr(SizeOf(Dashes) -1);
Writeln(Dashes);
Writeln('The length of Dashes is ',Length(Dashes));
Writeln('The Size of Dashes is ',SizeOf(Dashes));
END.
resulted in the following.
Running
--------------------
The length of Dashes is 20
The Size of Dashes is 21

Msg # 167 Dated 03-17-87
From: HOWARD SANNER
To: ALL
Re: LENGTH(S)
Turbo Pascal's built-in function LENGTH() is much slower than
inspecting the zeroth element of the string by using Ord(S[0]).
Ord(S[0]) generates three assembly language instructions;
Length(S) generates about a page full.


Msg # 168 Dated 03-18-87
From: BILL MAYNE
To: BILL FOWLER
You are right that the code as I entered it in the last message
would not work as intended. I meant to say:
FillChar(dashes[1],sizeof(dashes)-1,'-');
dashes[0]:=chr(sizeof(dashes)-1);
The critical thing I left out was the subscript so the filling
of 'dashes' started with the second byte, allowing for the 0'th
byte which holds the length. If you include the '[1]' subscript
it shouldn't matter which order the two statements go in.
It is my assumption that expressions like:
sizeof(dashes)-1
are evaluated at compile time and don't generate any extra
object code. Could someone more enlightened about the workings
of TP confirm or deny?
Along the same lines, what about the 'Ord' and 'Chr' functions,
which simply override type declarations. E.g. does
s[1]:=chr(byte_var);
generate essentially the same code as
s[1]:=char_var;

Msg # 170 Dated 03-20-87
From: KIRT UNDERCOFFER
To: BILL MAYNE
SizeOf(dashes) is a function evaluated at run time instead of
compile time. It is interesting that for strings this could have
been evaluated at compile time since you'r asking for the size
of the data structure. Interestingly, the string length
indicator (Dash[0] in this case) isn't affected in any way until
an explicit assignment expression. Why is that? Beats me. Some
would call this a bug in the implementation but it isn't really
since even for ISO Pascal such details are completely in the
hands of the implementor.But to save time they could have
evaluated the size at compile time and then ignored the explicit
call to the function to do it again. Maybe other problems pop
up if they try to optimize in this way although other tougher
optimization problems are overcome (or should be) in optimizing
for loops.Anyway, it's interesting to note that you can truncate
the string without any side effects if you manipulate the string
length indicator. Also ,if you do this the variable space isn't
reallocated - the original declaration of a string of size x
holds until program termination.The question you asked about
char and byte variable manipulation should hold particularly
after Borland's hype of Turbo as an optimizing compiler but the
only way to tell for sure is to run some experiments.The
question then is - does Turbo optimize for function calls that
are easy to handle at compile time or does it just blindly
generate code for function calls without checking a little bit?
I suspect the former.