Frank wrote:
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?
Short answer: the standard doesn't say anything about the correspondence between external objects and their internal representation.
The semantics of _internal_ files is simple: the size is initially undefined, `rewrite' makes it 0, and each `put' (performed at the end of the file) increments it by 1.
Basic behavior of _external_ files is the same, except that any property of the file (incl size) may be set to whatever value the compiler likes after a successful `bind', and any operation on a bound file may lead to an error or to some action on the external entity to which it is bound (again, the compiler is free to choose any action it wants).
Hence, from the standpoint of the standard, it doesn't matter which size is assigned to files of emptyrec, provided it is consistent with the behavior of other operations on the file (i.e., if the size is 0, the file should behave as empty; if it is 234, it should be possible to do 234 `read's from the file, after which `eof' should be true, etc).
Also, the RTS could simply refuse to `bind' such files, this would bypass the size question entirely.
Maybe the most simple solution is to pad each emptyrec in a file by 8 bits :-)
Emil
(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
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html