Emil Jerabek wrote:

...

After reading this message, I tried to experiment with set types a little bit. It turned out that the compiler segfaults on "set of Void" (this is a nonsense type, but anyway...)

GPC accepts "array of Void" (and even static variables of that type; should it?), but it crashes on "packed array of Void". More importantly, it crashes the same way on the following ISO 7185 code:

[...]

A similar file-type generates a run-time error:

Thanks for the reports. All fixed now (emil{12,13[a-c],14,15}.pas).

Frank

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

Here's the code of recordend3.pas:

----------- program FileTest (Output); {$macros}

const MaxLen = 100; Len = 42; TestPos = 13;

type EmptyType = record end;

var F: file of EmptyType; G: file [1 .. MaxLen] of EmptyType; I: Integer; OK: Boolean value True;

{$define Fail(Pass, Pos, Func, Result) begin WriteLn ('failed ', Pass, ': ', Pos : 5, ' ... ', Func, ' = ', Result); OK := False end }

begin Rewrite (F); for I := 1 to Len do begin if not EOF (F) then Fail (0, I, 'EOF', False); Put (F) end;

Reset (F); for I := 1 to Len do begin if EOF (F) then Fail (1, I, 'EOF', True); Get (F) end; if not EOF (F) then Fail (1, '(end)', 'EOF', False);

Rewrite (G); for I := 1 to Len do begin if not EOF (G) then Fail (2, I, 'EOF', False); if Position (G) <> I then Fail (2, I, 'Position', Position (G)); Put (G); if LastPosition (G) <> I then Fail (2, I, 'LastPosition', LastPosition (G)) end;

Reset (G); for I := 1 to Len do begin if EOF (G) then Fail (3, I, 'EOF', True); if Position (G) <> I then Fail (3, I, 'Position', Position (G)); Get (G) end; if not EOF (G) then Fail (3, '(end)', 'EOF', False);

if Empty (G) then Fail (3, '(end)', 'Empty', True);

SeekUpdate (G, TestPos); Update (G); if EOF (G) then Fail (4, TestPos, 'EOF', True); if Position (G) <> TestPos then Fail (4, TestPos, 'Position', Position (G)); if LastPosition (G) <> Len then Fail (4, TestPos, 'LastPosition', LastPosition (G));

if OK then WriteLn ('OK') end. ----------------------

Emil Jerabek

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