[Oberon] NEW on POINTER TO RECORD always results in NIL (RISC Oberon) - bug?

[Jörg Straube]

Michael

Indeed, seems a compiler bug :-(

The following source
   MODULE BugTest;
   VAR
     v1: POINTER TO RECORD a: INTEGER END;
   BEGIN
     NEW(v1)
   END BugTest.

generates this code (compiled with "OR compiler 15.12.2013")

type descriptors  <-- empty list!! WRONG :-(
code
  LDR SB R0 2
  ADD R0 SB 0  <-- put address of "v1" into R0
  ADD R1 SB 0  <-- put address of type tag into R1 (wrong address!!)
  BL MT             <-- call Kernel.New
pointer refs
  0                     <-- address of "v1"

The compiler "forgot" to generate a correct type tag for the unnamed type "RECORD a: INTEGER END" and hence Kernel.New does not know how many bytes to allocate.

Instead if you write
   MODULE CorrectTag;
   TYPE
      R = RECORD a: INTEGER END;
   VAR
     v1: POINTER TO R;
   BEGIN
     NEW(v1)
   END CorrectTag.

the compiler generates the correct code
type descriptors
  00000020 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF <-- type tag for R
code
  LDR SB R0 2
  ADD R0 SB 20  <-- put address of "v1" into R0
  ADD R1 SB 0    <-- put address of R's type tag into R1
  BL MT               <-- call Kernel.New
pointer refs
  20                     <-- address of "v1"

br
Jörg
Am 19.05.2014 um 23:05 schrieb Michael Schierl <schierlm at gmx.de>:

> [I tried to post this message about a month ago and never received any
> feedback - seems that it never got approved. Now that I'm subscribed to
> the list, I'll try again :)]
> 
> 
> Hello,
> 
> 
> When trying to compile this short example in RISC Oberon (using the
> Windows emulator/distribution from projectoberon.com):
> 
> -------------------------------------------
> MODULE BugTest;
>  IMPORT Texts, Oberon;
>  TYPE
>    P1 = POINTER TO P1Desc;
>    P1Desc = RECORD a: INTEGER END;
>    P2 = POINTER TO RECORD a: INTEGER END;
> 
> 
>  PROCEDURE DebugPrint(VAR str : ARRAY OF CHAR);
>  VAR w : Texts.Writer;
>  BEGIN
>    Texts.OpenWriter(w);
>    Texts.WriteString(w,str);
>    Texts.WriteLn(w);
>    Texts.Append(Oberon.Log, w.buf);
>  END DebugPrint;
> 
>  PROCEDURE TestAlloc*();
>    VAR
>      v1: P1;
>      v2: P2;
>      v3: POINTER TO P1Desc;
>      v4: POINTER TO RECORD a: INTEGER END;
>  BEGIN
>    NEW(v1);
>    IF v1 # NIL THEN DebugPrint("OK1") ELSE DebugPrint("NIL1") END;
>    NEW(v2);
>    IF v2 # NIL THEN DebugPrint("OK2") ELSE DebugPrint("NIL2") END;
>    NEW(v3);
>    IF v3 # NIL THEN DebugPrint("OK3") ELSE DebugPrint("NIL3") END;
>    NEW(v4);
>    IF v4 # NIL THEN DebugPrint("OK4") ELSE DebugPrint("NIL4") END;
>  END TestAlloc;
> END BugTest.
> -------------------------------------------
> 
> It always outputs "OK1 OK2 OK3 NIL4" into the Log (I'd have expected
> that it printed OK4 as well).
> 
> Is that a bug in the compiler, or actually intended behavior?
> 
> The actual code I'm using is a bit more complex (I'm playing with adding
> paravirtualized clipboard support and some more things to the emulator;
> if I ever get it working fine, I'll release patches of course, unless
> anyone beats me to it  [edit: which I succeeded and a changed version
> that did not require the kludge that made me find this bug was
> successfully merged into Peter De Wachter's emulator]), and it took me
> quite some time to track down that issue...
> 
> 
> Regards,
> 
> 
> Michael
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3644 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20140521/4f9b1407/attachment.bin