Emil Jerabek wrote:
Sorry, should think twice before submitting a bugreport. The story with "file of record end" is more complicated then I wrote.
The test below should pass for any type (which is permissible as a file component-type, of course). It indeed works with, say, "file of Integer", but with the empty record type it fails:
[pas]% gpc -v Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20020318, based on 2.95.2 19991024 (release) [pas]% gpc recordend3.pas [pas]% ./a.out failed 1: (end) ... EOF = False zsh: floating point exception (core dumped) ./a.out
Apparently, the RTS doesn't track the length and current position of file variables, and tries to compute them from the byte-size of the file when needed. This is wrong for "file of record end" and similar beasts, because
(i) it makes EOF always return False (in Inspection mode, at least)
(ii) most direct access functions raise a "division by zero" signal
That's true. Since you agreed that this is "completely pointless" in practice, and it's not trivial to fix, I'll assign it a rather low priority (emil16.pas).
However, maybe it would make the code somewhat cleaner in general to track the current position, so I'll think about it.
Though one question remains: What *should* the size of a file of emptyrec actually be? If the external file is empty, it's undefined (0/0), otherwise it's infinite (n/0, n>0). Has the standard got anything to say about it? Otherwise, what would be most reasonable? Perhaps MaxInt?
(All other Pascal compilers I have handy, i.e. BP and an older version of FPC, choke on it as well, so there doesn't seem to be any precedence.)
Frank