One of my programs, which I have used with many compilers in the past, started an odd behavior as soon as I compiled with GPC. I rooted down to what the cause was and found this:
EOF is not true on a reset empty file.
Here is the program:
******************************************************************************** program gpcbug2005jan27(namebook, namelist, output); (* Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const version = 1.00; (* of gpcbug2005jan27.p 2005 jan 27 *)
var namebook, namelist: text;
begin reset(namebook); if eof(namebook) then writeln(output,'eof of namebook') else writeln(output,'NOT eof of namebook');
reset(namelist); if eof(namelist) then writeln(output,'eof of namelist') else writeln(output,'NOT eof of namelist'); end. ********************************************************************************
This is the result of running a script called mk (which displays itself):
******************************************************************************** version = 1.00 of mk 2005 Jan 27 #!/bin/tcsh -f #(ie run the tshell on this but don't read the .cshrc or .tcshrc)
echo version = 1.00 of mk 2005 Jan 27 # 2005 Jan 27, 1.00: origin
# show the script that does everything: cat mk
echo -n "" > namebook echo -n "" > namelist
echo 'file name*' file name*
echo echo 'wc -l name*' wc -l name*
echo echo 'ls -l name*' ls -l name*
echo -------------------- compile gpcc gpcbug2005jan27.p echo --------------------
gpcbug2005jan27 file name* namebook: empty file namelist: empty file
wc -l name* 0 namebook 0 namelist 0 total
ls -l name* -rw------- 1 toms delila 0 Jan 27 02:25 namebook -rw------- 1 toms delila 0 Jan 27 02:25 namelist -------------------- compile version = 1.37 of gpcc 2004 Jan 11 Using /usr/local/gpc/bin/gpc instead of the one in the path gpc compiling gpcbug2005jan27.p output program name: gpcbug2005jan27 gpcbug2005jan27.p exists, so we can delete gpcbug2005jan27: REMOVING gpcbug2005jan27 version = 1.00; (* of gpcbug2005jan27.p 2005 jan 27 *) optimization: 0 --- GPC version from "gpc --version | head -1" : gpc 20040516, based on gcc-3.3.3 GPC version from "gpc | head -1" : GNU Pascal version 20040516, based on gcc-3.3.3. --- ONLY STANDARD PASCAL IS ALLOWED
------ No errors ------ No warnings ------
gpcc is done -------------------- NOT eof of namebook NOT eof of namelist ********************************************************************************
Is this standard behavior for Pascal? I thought that if you reset an file, it would be at eof. Where else could it be?
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/
One of my programs, which I have used with many compilers in the past, started an odd behavior as soon as I compiled with GPC. I rooted down to what the cause was and found this:
EOF is not true on a reset empty file.
Here is the program:
<snip>
echo -------------------- compile gpcc gpcbug2005jan27.p echo --------------------
<snip>
You missed an important information. If I type (with `eof.pas' beeing your file): ../gpc-3.4.3/gcc/xgpc -B../gpc-3.4.3/gcc/ -O -ftransparent-file-names -fstandard-pascal eof.pas ./a.out
I get: NOT eof of namebook NOT eof of namelist
However, if I type: ../gpc-3.4.3/gcc/xgpc -B../gpc-3.4.3/gcc/ -O --transparent-file-names eof.pas ./a.out
I get: eof of namebook eof of namelist
Both with my (modified) copy of gpc-20041218 on Linux. Yes, standard requires that you get EOF on empty file.
Tom Schneider wrote:
One of my programs, which I have used with many compilers in the past, started an odd behavior as soon as I compiled with GPC. I rooted down to what the cause was and found this:
EOF is not true on a reset empty file.
<snip>
Is this standard behavior for Pascal? I thought that if you reset an file, it would be at eof. Where else could it be?
There is a little tricky point here: the standard requires read from text file to give eoln and a space character before eof. So GPC runtime adds a newline before eof if original file contained no newline. That was wrong for empty file. The following patch should fix the problem (apply it relatively to gpc-20041218/p directory):
--- rts/files.pas.bb 2005-01-30 00:55:45.498296856 +0100 +++ rts/files.pas 2005-01-30 00:55:51.371404008 +0100 @@ -1259,7 +1259,10 @@ end;
procedure ReadBuffer (f: GPC_FDR); +var WasRead: boolean; begin + WasRead := not f^.Status.Unread; + f^.Status.Unread := false; f^.BufPos := 0; if f^.ReadFunc <> nil then begin @@ -1277,7 +1280,8 @@ it prevents detecting whether there actually is an EOLn in the file. } if f^.BufSize <> 0 then f^.Status.LastEOLn := f^.BufPtr^[f^.BufSize - 1] = NewLine - else if ((RTSOptions and ro_SP_EOLn) <> 0) and f^.Status.Text and not f^.Status.LastEOLn then + else if ((RTSOptions and ro_SP_EOLn) <> 0) and f^.Status.Text + and not f^.Status.LastEOLn and WasRead then begin f^.Status.LastEOLn := True; f^.BufPtr^[0] := NewLine; @@ -1716,7 +1720,6 @@ n: SizeType; begin if not CheckReadableNotEOF (f) then Exit; - f^.Status.Unread := False; f^.Status.Undef := False; f^.Status.LGet := False; { @@ this different treatment is suspicious }
Waldek Hebisch wrote:
Tom Schneider wrote:
One of my programs, which I have used with many compilers in the past, started an odd behavior as soon as I compiled with GPC. I rooted down to what the cause was and found this:
EOF is not true on a reset empty file.
<snip> > Is this standard behavior for Pascal? I thought that if you reset > an file, it would be at eof. Where else could it be?
There is a little tricky point here: the standard requires read from text file to give eoln and a space character before eof. So GPC runtime adds a newline before eof if original file contained no newline. That was wrong for empty file.
Indeed (it's really tricky ...).
The following patch should fix the problem (apply it relatively to gpc-20041218/p directory):
Yes, thanks. (tom7.pas)
Frank