Scott Moore wrote:
... snip ...
write(''''); while not eof(f) do begin
if eoln(f) then write('<eoln>'); read(f, c); write(c)
end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> ''');
end.
The results from GPC for running this command are as follows:
C:\TEST>test 'how now<eoln> brown cow<eoln> ' s/b 'how now<eoln> brown cow<eoln> ' 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> '
... snip ...
In effect, the program processor must arrange for eoln to be true at the end of a file, either by faking it while reading, or by forcing an eoln to be written at the end of a file during generation.
I think I disagree with the test. A file needs to be correctly read by:
WHILE NOT eof(f) DO get(f); WHILE not eoln(f) DO BEGIN output^ = f^; put(output); get(f); END; writeln; END;
and the shortcuts of using read and write should be correct if they are correctly implemented. FOR MALFORMED files this means that the appearance of eof during reading must set the eoln condition if not already set, and that a get must not be an error if eoln is true and the file is at actual eof. Now we have to reconcile this with the need for error if another get is performed, but not if another eoln test is made. This means an invisible flag somewhere to me, reset by performing a get when eoln is true and set by reaching the actual (invisible) eof.
It should not be possible to generate such a malformed text file within the Pascal system. The act of closing should detect the missing final writeln, and perform it. It doesn't matter whether the close is the result of a reset or rewrite or scope exit, or even an extension standard procedure close. The first action in those cases should be: "If the file is open, close it." There may be gyrations needed to preserve the file name under a reset or rewrite. Note that all this implies programmer invisible automatic initialization of a file variable. It is not trivial to get it all right.
At any rate, if we can't generate such a file, it is hard to test for proper action on reading them without having test files generated outside the system. Thus this business really becomes a matter of QOI rather than standards compliance.