Ok, so what behavior were you expecting?

"it shall be an error if f is undefined or if eof(f) is true" says that eoln() is invalid
when eof(f) is true. The phrase "it shall be an error" means in the language of the
standard that "it is wrong". This means that if eof(f) is true, then the result of
eoln() can be true, false, or a ham sandwich on rye.

The ideal behavior, according to the standard (but is optional!) is to fault and terminate
the program with a message if you read eoln() while eof() is true.

Is that what you wanted?

Scott

Humm, a ham sandwich sounds good right now.....
-------- 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.