mesp@cc.newcastle.edu.au (Simon Plint) (04/23/91)
Could someone tell me why,when I use a read or readln within a loop in Think Pascal, I get an error saying something about the end of the file being reached. Thanks ------------------------- Simon Plint
mrhoten@neon.Stanford.EDU (Matthew Paul Rhoten) (04/23/91)
In article <1991Apr23.132502.10012@cc.newcastle.edu.au> mesp@cc.newcastle.edu.au (Simon Plint) writes: >Could someone tell me why,when I use a read or readln within a loop >in Think Pascal, I get an error saying something about the end of >the file being reached. >Thanks >------------------------- > Simon Plint It is an error to call read(afile, stuff) or readln(afile, stuff) while eof(afile) is true. With text files, it gets worse: Since read or readln may read more than one character, it may be an error (depending on the input file) to call read or readln even when eof is not true. For instance, if your file is a bunch of strings, one per line, and you call readln(infile, mystring), the program reads stuff until it hits the eoln marker. If there is no eoln marker after the last line in the file, the readln attempts to read past the end of the file, which creates a runtime error of some sort. Another situation in which this can come up is using the keyboard as an input device. The enter key on the numeric keypad (at least on my SE/30) causes eof on standard input to return true. The return key causes eoln on the standard input to return true. (This might be considered a more intuitive behavior for the enter key, but it just doesn't work that way.) So, typing in stuff on the keypad and hitting the obvious enter key stops the program with an 'unexpected end of file' error, typically. One way to get around this is to stuff a character at a time and test for eof, then eoln. (Note that eoln is undefined when eof is true.) This introduces some performance bottlenecks, though, if the file volumes are large. In this case you might be better off using the File Manager calls such as FSRead which can read in huge gobs of input at once, albeit with no processing that readln would do for you. Hope this helps. -matt -- Matt Rhoten | PO Box 10031 | Standard disclaimers apply. mrhoten@cs.stanford.edu | Stanford, CA 94309 | (415) 497-2853 | veni vidi vomui