I wrote before:
EOF is not true on a reset empty file.
for GPC.
gpc 20040516, based on gcc-3.3.3
I just found in the book
PASCAL User Manual and Report, Fourth Edition ISO Pascal Standard, Kathleen Jensen and Niklaus Wirth 1991 page 158:
"A file is called \emph{empty} if its length is zero."
As you can see in the previous email, I created two empty files with echo -n "" > filename and then showed by three tests (file, ls and wc) that they were empty. In the GPC compiled program, I reset each file and then tested them and found that each was not at eof.
Regards,
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/
Tom Schneider wrote:
I wrote before:
EOF is not true on a reset empty file.
for GPC.
gpc 20040516, based on gcc-3.3.3
I just found in the book
PASCAL User Manual and Report, Fourth Edition ISO Pascal Standard, Kathleen Jensen and Niklaus Wirth 1991 page 158:
"A file is called \emph{empty} if its length is zero."
As you can see in the previous email, I created two empty files with echo -n "" > filename and then showed by three tests (file, ls and wc) that they were empty. In the GPC compiled program, I reset each file and then tested them and found that each was not at eof.
Regards,
Tom
I think, in the long run, GPC will be the best Pascal choice. But your important efforts to re-establish Pascal in your area of research don't have the luxury of time. If you have not tried the Free Pascal Compiler, it might be worth a try. Sincerely, Rick.
Tom Schneider a écrit:
I wrote before:
EOF is not true on a reset empty file.
for GPC.
gpc 20040516, based on gcc-3.3.3
I just found in the book
PASCAL User Manual and Report, Fourth Edition ISO Pascal Standard, Kathleen Jensen and Niklaus Wirth 1991 page 158:
"A file is called \emph{empty} if its length is zero."
As you can see in the previous email, I created two empty files with echo -n "" > filename and then showed by three tests (file, ls and wc) that they were empty. In the GPC compiled program, I reset each file and then tested them and found that each was not at eof.
Strange. doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 behaves as expected. All is done manually with suitable tools to binary visualize the true content of files, no shell scripts or functions which could be too intelligent (I have bash, no tcsh) and hide something "unimportant", for example no linefeed or ^Z (a DOS nicety on text files) added at the end.
A side comment: to make it work I needed to compile with gpc add the --transparent-file-name option to gpc (otherwise the filenames are asked at the beginning of the execution) Why did you not need it ?
Maurice
Maurice Lombardi a écrit:
Tom Schneider a écrit:
I wrote before:
EOF is not true on a reset empty file.
for GPC.
gpc 20040516, based on gcc-3.3.3
I just found in the book PASCAL User Manual and Report, Fourth Edition ISO Pascal Standard, Kathleen Jensen and Niklaus Wirth 1991 page 158:
"A file is called \emph{empty} if its length is zero."
As you can see in the previous email, I created two empty files with echo -n "" > filename and then showed by three tests (file, ls and wc) that they were empty. In the GPC compiled program, I reset each file and then tested them and found that each was not at eof.
Strange. doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 behaves as expected. All is done manually with suitable tools to binary visualize the true content of files, no shell scripts or functions which could be too intelligent (I have bash, no tcsh) and hide something "unimportant", for example no linefeed or ^Z (a DOS nicety on text files) added at the end.
An afterthought What if you eliminate the problems which may be due to the shell by creating the empty files by the pascal program itself e.g. ----------------------------------------------------------------------- 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 rewrite(namebook); close(namebook);
reset(namebook); if eof(namebook) then writeln(output,'eof of namebook') else writeln(output,'NOT eof of namebook');
rewrite(namelist); close(namelist);
reset(namelist); if eof(namelist) then writeln(output,'eof of namelist') else writeln(output,'NOT eof of namelist'); end. -----------------------------------------------------------
Files are created by the rewrite, and you can inspect the resulting files to be sure they are empty. You can also write a separate program to create the files.
Maurice
On Thu, Jan 27, 2005 at 05:41:49PM +0000, Maurice Lombardi wrote: [...]
A side comment: to make it work I needed to compile with gpc add the --transparent-file-name option to gpc (otherwise the filenames are asked at the beginning of the execution)
Incidentally, I tried it without --transparent-file-names (gpc 20041218, gcc 3.3.3), and got:
[~/pas]% ./a.out Input file `namebook': namebook ./a.out: cannot open file `namebook ' for reading (No such file or directory) (error #442 at 8049e79)
I.e., the name of the file includes the newline which is necessary to terminate the input! This is IMO another bug.
Emil
Emil Jerabek wrote:
Incidentally, I tried it without --transparent-file-names (gpc 20041218, gcc 3.3.3), and got:
[~/pas]% ./a.out Input file `namebook': namebook ./a.out: cannot open file `namebook ' for reading (No such file or directory) (error #442 at 8049e79)
I.e., the name of the file includes the newline which is necessary to terminate the input! This is IMO another bug.
Yes, this bug slipped in when I ported the file handling from C to Pascal.
--- rts/files.pas.orig Sun Nov 14 04:38:58 2004 +++ rts/files.pas Fri Jan 28 14:16:01 2005 @@ -1154,7 +1154,7 @@ if Tty >= 0 then Discard (CloseHandle (Tty)); if (n > 0) and (Buf2[1] = EOT) then IOERROR_FILE (421, f, False, ''); { EOT character given for query of file name for %s } - if (n > 0) and (Buf2[n] = '\n') then Dec (n); + if (n > 0) and (Buf2[n] = NewLine) then Dec (n); Inc (n); Buf2[n] := #0; Tmp := InternalNew (n);
Frank
- if (n > 0) and (Buf2[n] = NewLine) then Dec (n);
Does this cope with famous <cr><lf> ? Jan
On Jan 28, 2005, at 08:16, Frank Heckenbach wrote:
Emil Jerabek wrote:
Incidentally, I tried it without --transparent-file-names (gpc 20041218, gcc 3.3.3), and got:
[~/pas]% ./a.out Input file `namebook': namebook ./a.out: cannot open file `namebook ' for reading (No such file or directory) (error #442 at 8049e79)
I.e., the name of the file includes the newline which is necessary to terminate the input! This is IMO another bug.
Yes, this bug slipped in when I ported the file handling from C to Pascal.
--- rts/files.pas.orig Sun Nov 14 04:38:58 2004 +++ rts/files.pas Fri Jan 28 14:16:01 2005 @@ -1154,7 +1154,7 @@ if Tty >= 0 then Discard (CloseHandle (Tty)); if (n > 0) and (Buf2[1] = EOT) then IOERROR_FILE (421, f, False, ''); { EOT character given for query of file name for %s }
- if (n > 0) and (Buf2[n] = '\n') then Dec (n);
- if (n > 0) and (Buf2[n] = NewLine) then Dec (n); Inc (n); Buf2[n] := #0; Tmp := InternalNew (n);
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
jan.ruzicka@comcast.net wrote:
- if (n > 0) and (Buf2[n] = NewLine) then Dec (n);
Does this cope with famous <cr><lf> ? Jan
On Jan 28, 2005, at 08:16, Frank Heckenbach wrote:
The file is opened in text mode (i.e., without `O_BINARY', in C terms), so the system library deals with that. Tested on DJGPP.
Frank