[Oberon] Array Index Out Of Range in ORG.FindPtrFlds

[Andreas Pirklbauer]

> >   MODULE M2;
> >     TYPE P = POINTER TO R;
> >       R = RECORD a: ARRAY 160 OF P END ;    (*trap 1*)
> >   END M2.
> >
> > Any suggestions how to address that in program M2?
> >
>
> What practical problem are you trying to solve with example M2?
> 
> If I just wanted a list of pointers I would use a static array e.g.
>
> MODULE M3;
>     TYPE P = POINTER TO R;
>        R = RECORD a: ARRAY 160 OF INTEGER END ;
>     A = ARRAY 200 OF P;
> END M3.
>
> —
> Regards,
> Chris Burrows
> 

I have adapted the inner core to allow for *arbitrary* file sizes, 
using a Unix-like inode structure both on disk and in-memory.

On disk, it’s easy as all reference are simply (integer) disk addresses.

But in-memory, I want to dynamically allocate *intermediate* nodes
(nodes containing “just” 256 pointers to other index nodes which then
contain actual disk addresses of data sectors) *only when needed*.

In Extended Oberon, the modification in Files.Mod is straightforward,
as one can just allocate a dynamic array of pointers whenever needed:

 MODULE Files;
   TYPE
        IndexTable = ARRAY FileDir.IndexSize OF Index;  (*<---*)
        FileDesc* = RECORD …
          sec: FileDir.SectorTable; (*direct data blocks*)
          ext: ARRAY FileDir.ExTabSize OF Index; (*single indirect blocks*)
          ind: POINTER TO IndexTable; (*<--- double indirect blocks*)
          ...
        END
 
   PROCEDURE Old*(name: ARRAY OF CHAR): File;
       …
       IF k > FileDir.ExTabSize THEN
         NEW(f.ind);   (*<--- allocate an array of pointers on the heap*)
         Disk.GetSector(F.ind, f.ind^)
       END

but in the FPGA Oberon version, I currently need to resort to
either a) or b):

a) allocate a record containing an array of INTEGER using NEW,
   but do plus some type casting back to pointers (=> ugly)

b) just increase the constant ORG.maxTD to e.g. 300
   (which actually works and which is what I currently use).

PS: I have played with a “compressed” representation of the
pointer locations in records containing arrays of pointers
(noting that the offsets simply repeat themselves N times in
an array) in ORG, but the result is just too cumbersome, as
such data structures can be defined recursively => not pursued.

In any case, I’ll use b) for now.

Regards,
Andreas