Emil Jerabek wrote:
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.
Oh yeah, right. ;-)
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.
For external files. For internal ones, we'd still have to keep track of the size.
Maybe the most simple solution is to pad each emptyrec in a file by 8 bits :-)
Good idea! I prefer this, especially because it's very easy to do. :-)
So this problem is fixed now (emil16.pas).
Frank