Opinion: folks often get confused about the intent vs the letter of the standard. With the above and

the section:

eoln(f)

The parameter f shall be a textfile ; if the actual-parameter-list is omitted, the function shall be applied to the required textfile input (see 6.10) and the program shall contain a program-parameter-list containing an identifier with the spelling input. When eoln(f) is activated, it shall be an error if f is undefined or if eof(f) is true ; otherwise, the function shall yield the value true if f.R.first is an end-of-line component (see 6.4.3.5) ; otherwise, false.

Realize that the standard has told you:

1. don't perform an eoln() when eof() is true. You may be terminated. You may get the wrong

answer (in fact, because the operation is invalid, ANY answer eoln() gives is by definition wrong.

2. We are not going to consider the compiler "bad" if it does not detect YOUR invalid call to eoln().

it was your job to make sure eof() was not true before calling eoln().

3. A "super quality" implementation would terminate your program with an error printout (but realize

that an equally high quality implementation might choose not to on the grounds that the check itself

takes time and slows the program down!).

Niklaus Wirth sculpted these areas of the language using the concept of "undefined", as in

"it is undefined if you check eoln() when eof is true". The standards makers redid this using the

concrete sounding "error", but the net result is the same. We have done a poor job of teaching

programmers that, rather than being an annoying factor that should be wiped out, what is

"undefined" for the field equation that is a working language is as important as what is defined

in the language itself. But then, we have done a poor job of teaching language theory to

programmers in general these days.

-------- Original Message --------
Subject: Re: More issues with EOLN, EOF, and the Pascal standard.
From: Chad Simmons <polpak@yahoo.com>
Date: Thu, September 24, 2009 2:25 pm
To: samiam@moorecad.com
Cc: gpc@gnu.de



--- On Thu, 9/24/09, samiam@moorecad.com <samiam@moorecad.com> wrote:
> However! In the very difficult to read
> part of 6.4.3.5 it specifies that eoln()s shall be forced to
> exist in a textfile if they don't exist, ie.,
> if the true end of the file is encountered, then an eoln()
> shall effectively be insertedbefore the file end.
> This is not inconsistent with 6.6.6.5, because eof() will
> not be true even though the true endof the file
> has been reached. Therefore, eof() and eoln() will not both
> be true at the same time.

Yes, and GPC currently does (when compiled with --classic-pascal) insert the extra newline in the case that none exists when eof is reached. The problem occurs after that extra newline has been read, eoln still returns true but now you are at the end of file, and there is no additional newline, so any attempt to read it will give an error that you're attempted to read past eof. It seems very unusual to me that the program returns true for both EOF and EOLN when you are not in fact at the end of a line.