http://www.standardpascal.org/iso7185.html

6.6.6.5 Boolean functions

...

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.

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 text

file if they don't exist, ie., if the true end of the file is encountered, then an eoln() shall effectively be inserted

before the file end. This is not inconsistent with 6.6.6.5, because eof() will not be true even though the true end

of the file has been reached. Therefore, eof() and eoln() will not both be true at the same time.

The standard behavior was designed to allow you to create loops to check eoln() only, then check eof() afterwards.

Ie.,

program x(input);

begin

if not eof then begin while not eoln do begin ... end; readln end

...

end;

is valid because if the file is completely empty, then it must have a series of complete lines (even if the compiler

has to simulate inserting them).

-------- Original Message --------
Subject: Re: More issues with EOLN, EOF, and the Pascal standard.
From: Waldek Hebisch <hebisch@math.uni.wroc.pl>
Date: Thu, September 24, 2009 11:59 am
To: gpc@gnu.de

Chad Simmons wrote:
> In a continuation of the thread:
>
> http://www.gnu-pascal.de/crystal/gpc/en/raw-mail10017.html
>
> Regarding conformance to the ISO 7185. It seems that GPC will correctly report EOLN before EOF even when none exists in the file. However, after successfully reading the end of line character, EOLN will still return true while EOF also simultaneously returns true.
>
> This has a tendency to give odd results. EOF and EOLN should be mutually exclusive. If the file doesn't properly have it's end of line marker before the end of the file, GPC can, should, and does currently insert the end of line into the buffer. But once it's been read, EOF should return true, and EOLN should not.
>

Why do you think so? Concerning conformance, the standard says
that calling EOLN when EOF is true is an error. In other words
conformat program befor calling EOLN should check that EOF is false.
And GPC compiled program is free to do anything if you call EOLN when
EOF is true: it can return true, it can return false, it can singal
error, it can simply crash.

So the question is what is most convenient. Returning true means
to the idiom 'not(eoln)' has clear meaning: there is something to
read. While one can probably give good justification to returning
false, changing behaviour now would almost surely break some
real programs, so change would be not wise.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl