[Oberon] Serious type loophole in type case statements and a possible fix

[Jörg]

When the compiler automatically generates a type guard (ORG.TypeTest) for all assignments to p in the CASE, shouldn’t that catch your case?

Br Jörg

> Am 30.10.2020 um 23:05 schrieb Michael Schierl <schierlm at gmx.de>:
> 
> Hello Andreas,
> 
> 
>> Am 30.10.2020 um 14:05 schrieb Andreas Pirklbauer:
>> The official Oberon-07 compiler, as published at www.projectoberon.com,
>> contains a serious type loophole in type case statements
>> 
> 
> [...]
> 
> 
>> but continues to ALLOW…
>> 
>>    1. Local variables or parameters (value or VAR) parameters as case variables
> 
> I think this can be exploited:
> 
> MODULE TestB;
>  IMPORT Texts, Oberon;
> 
>  TYPE R0 = RECORD END;
>    R1 = RECORD (R0) fld1: SET END;
>    R2 = RECORD (R0) fld2: INTEGER END;
>    P0 = POINTER TO R0;
>    P1 = POINTER TO R1;
>    P2 = POINTER TO R2;
> 
>  VAR p0: P0; p1: P1; p2: P2; W: Texts.Writer;
> 
>  PROCEDURE checkA(VAR p: P0);
>  BEGIN
>    CASE p OF P1:
>        p0 := p2;
>        p.fld1 := {4,1}
>    END;
>    Texts.WriteInt(W, p2.fld2, 4);     (*18*)
>    Texts.Append(Oberon.Log, W.buf)
>  END checkA;
> 
>  PROCEDURE Go*;
>  BEGIN p0 := p1; checkA(p0)
>  END Go;
> 
> BEGIN NEW(p1); NEW(p2); Texts.OpenWriter(W)
> END TestB.
> 
> 
> Using a real (but harmless) type confusion from SET to INTEGER to prove
> the point better :-)
> 
> This can obviously can be more convoluted/sophisticated, and I can't
> think of an easy way to fix it without disallowing POINTER VAR
> parameters altogether.
> 
> 
> Regards,
> 
> 
> Michael
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon