How does writeln knows its the end of a string? I have the following code:
String = packed array[1..256] of char;
var Test: String;
begin Test:='Hello world'; writeln (Test); Test[8] := Test[12]; writeln (Test); end.
The output is:
Hello world
Hello w rld
How does writeln knows where to stop printing the string?
__________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
On Mar 13, 2005, at 7:57 AM, loop lopy wrote:
How does writeln knows where to stop printing the string?
If it's a Pascal string, the first byte shows the length of the string. In other words, this assignment:
myS:= 'Test';
puts the value of 4 in the first byte. Your "test[8]:= test[12];" simply grabbed whatever was hanging in memory at the location one past the end of your string and copied it over.
dale
loop lopy wrote:
How does writeln knows its the end of a string? I have the following code:
String = packed array[1..256] of char;
var Test: String;
begin Test:='Hello world'; writeln (Test); Test[8] := Test[12]; writeln (Test); end.
The output is:
Hello world
Hello w rld
How does writeln knows where to stop printing the string?
It doesn't. "Writeln(something)" is specified as shorthand for "write(something); writeln".
However write knows that you specified the string to be an array of 256 chars, so it outputs 256 chars (unless told to truncate by a field specification). Those chars have somehow become blanks in your system, and that part is not standard. The assignment to test evidently has been arranged to append blanks, and it also appears as if the write operation has been arranged to elide trailing blanks, at least when the line is ended by the writeln operation. Strictly speaking the assignment to test should have raised an error.
The only function of a naked writeln is to terminate the current line.
CBFalconer wrote:
However write knows that you specified the string to be an array of 256 chars, so it outputs 256 chars (unless told to truncate by a field specification). Those chars have somehow become blanks in your system, and that part is not standard.
It is standard -- Extended Pascal, to be precise.
The assignment to test evidently has been arranged to append blanks, and it also appears as if the write operation has been arranged to elide trailing blanks, at least when the line is ended by the writeln operation.
It doesn't. Perhaps the spaces were just trimmed when copied into the mail.
BTW, the OP might want to use `--extended-pascal' or `--borland-pascal', unless your class has a strict requirement for the original standard language. (I'd recommend the former, but if you're somewhat familiar with Turbo (= Borland) Pascal as you indicated, you might prefer this. Both have a built-in string type (BP: `String[n]', EP: `String (n)').
a.d. jensen wrote:
On Mar 13, 2005, at 7:57 AM, loop lopy wrote:
How does writeln knows where to stop printing the string?
If it's a Pascal string, the first byte shows the length of the string. In other words, this assignment:
myS:= 'Test';
puts the value of 4 in the first byte.
The first byte applies only to BP's short strings. GPC's implements EP strings which store the length differently. From a user's point of view, it doesn't matter, except that they're not limited to 255 chars (unless you do dirty tricks such as accessing `s[0]').
In both cases, one can simply access `Length', and `Write' etc. obey the length automatically.
Frank
CBFalconer wrote:
loop lopy wrote:
How does writeln knows its the end of a string? I have the following code:
String = packed array[1..256] of char;
var Test: String;
begin Test:='Hello world'; writeln (Test); Test[8] := Test[12]; writeln (Test); end.
The output is:
Hello world
Hello w rld
How does writeln knows where to stop printing the string?
It doesn't. "Writeln(something)" is specified as shorthand for "write(something); writeln".
However write knows that you specified the string to be an array of 256 chars, so it outputs 256 chars (unless told to truncate by a field specification). Those chars have somehow become blanks in your system, and that part is not standard. The assignment to test evidently has been arranged to append blanks, and it also appears as if the write operation has been arranged to elide trailing blanks, at least when the line is ended by the writeln operation. Strictly speaking the assignment to test should have raised an error.
No, all elements of `Test' have well-defined value. It is standard: `Test' is padded with blanks to the full length (so all positions from 12 to 256 contain blanks). GPC `write' strips trailing blanks. You can try adding something like:
Test[70] := 'X';
before `writeln'.
For background: Standard Pascal was developed at the end of sixties and in early sevenites. At that time files in computers were frequently stored as a sequence of fixed length records-lines. The usual practice was to pad lines with blanks to full length (and truncate longer lines). When using variable lenght lines a conversion was needed: one had to strip trailing blanks from fixed length lines. Standard Pascal does not specify what happens to the files, to allow both fixed length lines and variable length lines.
Note: popular systems now use variable length lines, but Pascal Standard (ISO 7185) is from 1983, and the explicit goal was to describe original language, without adding extensions. The is newer standaed, Extended Pascal (ISO 10206) which among other extensions added support for true variable length strings. However loop lopy using `--standard-pascal' options explicitly requested GPC to reject newer additions.
a . d . jensen wrote:
If it's a Pascal string, the first byte shows the length of the string. In other words, this assignment:
myS:= 'Test';
puts the value of 4 in the first byte. Your "test[8]:= test[12];" simply grabbed whatever was hanging in memory at the location one past the end of your string and copied it over.
No, you write here about `short strings'. ATM GPC does not support short strings (there are plans to add them). The original program uses just blank padded array. GPC supports Extended Pascal strings, but those use separate (hidden) integer-sized length field. So also for EP strings access to byte 0 is invalid.
Waldek Hebisch wrote:
... snip ...
No, all elements of `Test' have well-defined value. It is standard: `Test' is padded with blanks to the full length (so all positions from 12 to 256 contain blanks). GPC `write' strips trailing blanks.
That would make it rather hard to move to an appropriate column with:
write(' '); or even: write(' ' : 5); or: i := 5; write(' ' : i);
all of which have applications. So the only thing that hangs together for me is for writeln to do the trailing blank stripping. Even this will make it hard to erase a line on a simple terminal.
CBFalconer wrote:
Waldek Hebisch wrote:
... snip ...
No, all elements of `Test' have well-defined value. It is standard: `Test' is padded with blanks to the full length (so all positions from 12 to 256 contain blanks). GPC `write' strips trailing blanks.
Does it? That's news to me. ;-) The code in predef.c uses `length = PASCAL_STRING_LENGTH (p);' and for fixed-strings, PASCAL_STRING_LENGTH takes the length of the array as declared, without trimming any blanks. The following program (compiled with or without `--classic-pascal') seems to confirm this.
program foo (Output);
var a: packed array [1 .. 10] of Char;
begin a := 'x '; Write (a, '.') end.
That would make it rather hard to move to an appropriate column with:
write(' ');or even: write(' ' : 5); or: i := 5; write(' ' : i);
all of which have applications.
Indeed. These things should work. I'm adding a test (chuck7.pas) which currently works, to ensure it will keep working.
So the only thing that hangs together for me is for writeln to do the trailing blank stripping. Even this will make it hard to erase a line on a simple terminal.
Yes, or to write text files with trailing spaces (for whatever reason one might want to do so), so I won't do this.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
Waldek Hebisch wrote:
... snip ...
No, all elements of `Test' have well-defined value. It is standard: `Test' is padded with blanks to the full length (so all positions from 12 to 256 contain blanks). GPC `write' strips trailing blanks.
Does it? That's news to me. ;-) The code in predef.c uses `length = PASCAL_STRING_LENGTH (p);' and for fixed-strings, PASCAL_STRING_LENGTH takes the length of the array as declared, without trimming any blanks. The following program (compiled with or without `--classic-pascal') seems to confirm this.
Right, I should have checked before writing.
-
a.d. jensen -
CBFalconer -
Frank Heckenbach -
loop lopy -
Waldek Hebisch