Testing LineCnt

Software Tools in Turbo Pascal

I intend to go through SOFTWARE TOOLS IN PASCAL by Kernighan & Plauger and to re-write the programs they presented using Turbo Pascal, taking advantage of Turbo Pascal's improvements over the...

RSS Feed

Author

Actor

I'm a retiree living in central Ohio. I've worked as an physicist, engineer, mathematician and programmer. Most of my experience has been with Fortran, Pascal and various versions of Basic. Pascal is by far my favorite language. I believe most of my programs are still in use.

Testing LineCnt

Ascii writes all the classic ascii characters to standard output or, if redirected, to a file. If run without redirection the programs seems to perform as expected. We get all the ascii characters including a line feed, chr(10), and a carriage return, chr(13). However, when we redirect the output to ascii.all and then display ascii.all using type we get considerably less output.

DOS displays various "non printing" characters as various symbols. Chr(1) is a smiley face. Chr(2) is a reverse smiley face. The next four characters, chr(3) .. chr(6) are the four suites of a deck of cards, etc.

The output of ascii.all via type is two lines. The first is short, ending with a diamond. Then other characters do not print but actually do something. Chr(7) gives us a beep. Chr(8) backspaces.

Of particular interest is chr(10), a line feed, which causes the cursor to drop down a line, and chr(13), a carriage return, which sends the cursor to the left edge of the screen causing subsequent characters to overwrite whatever was there.

When we get to chr(25) we get an arrow pointing down and the output terminates. Why? Because DOS uses the next char, chr(26), as end-of-file. Thus when we redirect output to ascii.all that’s as far as we get. When we use type to look at the file, that’s all there is.

On page 16 K&P present the following exercise.

"What happens if the last character of input to linecount is not a NEWLINE? Does the program stay sane? Is its behavior a bug or a natural consequence of our definition of a 'line'?"

ascii.all is just such a file, one whose last character is not a NEWLINE (CR + LF).

Linecnt < ascii.all

The answer is two. Why? Because the first ReadLn reads until it finds the carriage return. The second reads until it finds the end of file. In my opinion the output is sane and correct, and the behavior is not a bug.

I think K&P’s version would behave the same way if implemented in Turbo Pascal. Other implementations of Pascal might give different results.

Tags: None

Bookmark:

2 comments on "Testing LineCnt"

Posted by ghr on on Wednesday, January 02, 2008 at 12:15 PM

endfile constant
Again, interesting - with regards to chr(26), the EOF.

First, after redirecting the output to a file a 'dir' tells you that the file is significantly longer than say 26 bytes, in fact it is close to 128 bytes. So why can't we read beyond EOF in this case ?

Second, let's try it with another OS, e.g. UNIX. There again the file produced is about 128 bytes and we can read back all bytes as well !

My conclusion is: for PC only (and here XP behaves the same as DOS) you can change the original endfile constant from -1 into 26. For UNIX I would not recommend that: so for portability, stick to the original value.

Posted by Actor on on Saturday, January 12, 2008 at 8:21 PM

End of file
Thanks for the comment. You bring up some interesting points.

"First, after redirecting the output to a file a 'dir' tells you that the file is significantly longer than say 26 bytes, in fact it is close to 128 bytes. So why can't we read beyond EOF in this case ?"

I have no definitive answer, however, I have made some observations: * If you copy the file to another file, using the DOS COPY command, not the K&R program, the file size of 128 bytes is unaltered. * If you copy the file using Kopy (my version of the K&R program) the file size is reduced to 25 bytes. * Displaying the file on screen with the DOS TYPE command terminates the output at the 26th character, as previously stated. * The DOS program EDIT will load the entire file, not just the first 25 bytes. This is also true of MS WORD and NOTEPAD.

"Second, let's try it with another OS, e.g. UNIX. There again the file produced is about 128 bytes and we can read back all bytes as well !"

I would not expect another OS to behave the same as DOS.

"My conclusion is: for PC only (and here XP behaves the same as DOS) you can change the original endfile constant from -1 into 26. For UNIX I would not recommend that: so for portability, stick to the original value."

The problem with using -1 is that it does not map to a char value, i.e., Chr(-1) is an error. I have used Chr(255) which corresponds to -1 in twos complement arithmetic if you regard a Char as a signed integer, as I believe C does. The point is that I wish to preserve the Char type and to do that some value in the range 0 .. 255 must be chosen to represent ENDFILE. Chr(26) is as good as any.

The documentation of Turbo Pascal clearly states that the Read procedure will assign Chr(26) to a char variable if eof is TRUE. The fact that the DOS TYPE command sees Chr(26) as eof indicates that this is an attribute of DOS and not just of Turbo Pascal since DOS predates TP.

The lesson I take from this is to be aware that Chr(26) marks an end of file and to guard against its unexpected appearance, which can happen in compression and encryption programs. I.e., defend against it and be wary of expoiting it.

Testing LineCnt

Software Tools in Turbo Pascal

Subscribe

Author

Archive

Tags

Testing LineCnt