This very small program demonstrates a bug in handling FILEs of a particular RECORD. It has been cut down from a much larger real-life example, so it looks very artificial.

File F (a FILE of TSMALLPOINT) is not written correctly using GPC version 20010516 (based on 2.95.2 19991024 (release)) on Kernel 2.2.16 on an i686 under RedHat Linux 6.2.

The behaviour has changed sometime since version 19991030 (based on 2.95.2 19991024 (release)).

Here is the program: ====================

program daj23(input,output);

const MAXCOMP=5; MAXROUND=2; type TSMALLPOINT=RECORD REGNO:integer; PNTS:ARRAY[1..MAXROUND] OF integer; END;

var i,J,cat,count,ordinal:INTEGER; st1:string(255);

PROCEDURE SAVE_CAT;

VAR I,J:INTEGER; F:FILE OF TSMALLPOINT;

BEGIN

writeSTR(st1,CAT:1); REWRITE(F,'ch'+ST1);

F^.REGNO:=ORDINAL; for j:=1 to maxround do f^.pnts[j]:=0;

PUT(F);

FOR I:=1 TO MAXCOMP DO BEGIN F^.REGNO:=100+i;

FOR J:=1 TO MAXROUND DO BEGIN F^.PNTS[J]:=i+j; END;

PUT(F); END;

CLOSE(F); END;

begin (*daj20*) cat:=1; ordinal:=10; save_cat; end. (*daj20*)

od -d ch1 shows the file contains:

0000000 0 0 0 0 0 0 0 0 0000020 0 0 3 0 0 0 0 0 0000040 4 0 0 0 0 0 5 0 0000060 0 0 0 0 6 0 0 0 0000100 0 0 7 0 0000110

Under GPC version 19991030, od -d ch1 shows:

0000000 10 0 0 0 0 0 101 0 0000020 2 0 3 0 102 0 3 0 0000040 4 0 103 0 4 0 5 0 0000060 104 0 5 0 6 0 105 0 0000100 6 0 7 0 0000110

which is the correct contents.