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

[Andreas Pirklbauer]

No, they don’t need to be exported. Here is an even more minimal program showing the effect:

     MODULE M;
       VAR x: POINTER TO RECORD i: INTEGER END;

       PROCEDURE P*;
       BEGIN NEW(x); x.i := 0
       END P;

     END M.

The compiler compiles this program with no error message. But at runtime, multiple executions of the command M.P will lead to a trap.

I just noticed that nowhere in the Original Oberon system are pointer variables declared as shown above. They all point to *named* record types.

This makes me inclined to actually disallow the above program to be compiled. To achieve that, one would only have to change the language rule from “Pointers must point to records” to “Pointers must point to named records” in the language definition (see the last sentence in https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf <https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf> ) and adjust the proposed change to procedure ORP.Type0 accordingly:

  IF (type.base.form # ORB.Record) OR (type.base.typobj = NIL) THEN ORS.Mark("must point to named record”) END ;

Andreas

------------------------------------------------------------------------------------------------------------

Chris Burrows chris at cfbsoftware.com  Sat Sep 23 06:24:28 CEST 2017

I’m having difficulty understanding the possible intended use of your example. Did you really mean for x and y to be marked for export? If so, can you provide an example client module which would demonstrate how they could be usefully referenced?

 
Regards,

Chris Burrows
CFB Software

http://www.astrobe.com


------------------------------------------------------------------------------------------------------------

> On 22 Sep 2017, at 16:47, Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
> 
> 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;
>        TYPE R* = RECORD i: INTEGER END;
> 
>        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);
>        ...
>      BEGIN
>        ...
>        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 ;
>            CheckRecLevel(level)
>          END
>        ELSIF sym = ORS.procedure THEN ...
>        ELSE ...
>        END
>      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,
> AP
> 
> 

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