Zero-length types (was: Record

[Frank Heckenbach]

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

-- 
Frank Heckenbach, frank at 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