[Oberon] Bug in Oberon compiler? (no type descriptors created for anonymous record types)

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Fri Sep 22 17:03:00 CEST 2017

It seems that the Oberon 2013 compiler on RISC creates type descriptors only for *named* record types, but not for *anonymous* record types. This creates a problem if a dynamic variable pointing to an anonymous record type is allocated in the heap via the predefined procedure NEW.

For example, in the following test program:

     MODULE M;

       VAR x*: POINTER TO R;
         y*: POINTER TO RECORD x, y, z: INTEGER END;

       PROCEDURE P*;
       BEGIN NEW(x)
       END P;

       PROCEDURE Q*;
       BEGIN NEW(y)
       END Q;

     END M.

the pointer variable 'x' points to a dynamic record of *named* record type 'R' for which a type descriptor is created by the compiler when the declaration for 'R' is processed. However, the pointer variable 'y' points to an *anonymous* record type for which *no* type descriptor is created by the compiler. So the command M.Q will crash the system as soon as the garbage collector uses the type tag of ‘y' to access the (non existing) type descriptor of the anonymous record pointed to by ‘y’.

The proposed solution is to also creates a type descriptor for a variable declaration of a pointer variable pointing to an *anonymous* record type. This is achieved by adding a single line to procedure ORP.Type0:

     PROCEDURE Type0(Var type: ORB.Type);
       IF sym = ORS.ident THEN ...
       ELSIF sym = ORS.array THEN ...
       ELSIF sym = ORS.record THEN ...
       ELSIF sym = ORS.pointer THEN ...
         IF sym = ORS.ident THEN ...
         ELSE Type(type.base);
           IF type.base.form # ORB.Record THEN ORS.Mark("must point to record”)
-->      ELSIF (type.base.typobj = NIL) & (level = 0) THEN ORG.BuildTD(type.base, dc)    (*type descriptor; len used as its address*)
           END ;
       ELSIF sym = ORS.procedure THEN ...
       ELSE ...
     END Type0;

I’d be interested if anyone else has bumped into this issue before and whether there are any comments on the proposed solution. In particular, are there any other cases that should be considered and that people have reported before? Also, I have not tested the proposed solution with record extensions.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170922/ab22db1c/attachment.html>

More information about the Oberon mailing list