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

[Luca Boasso]

Yes I agree, as I mentioned in my last email my solution has a cost.
If we have to restrict the CASE probably I would rather pay the extra
runtime cost or remove this type functionality of the CASE altogether.

On Fri, Oct 30, 2020 at 9:37 AM Andreas Pirklbauer <
andreas_pirklbauer at yahoo.com> wrote:

>     > I remember reading about a similar issue related to the WITH
> statement of
>     > Oberon-90, so the way I solved this problem in oberonc is to add an
> additional
>     > type test each time the case variable is referred in the statements
> of a particular case label.
>
> Hi Luca,
>
> Yes, that’s of course the obvious solution. But that would re-introduce
> run-time
> overhead that the type case statement avoided in the first place. In that
> case, one
> might as well get rid of the CASE altogether and just use IF p IS T THEN
> instead:
>
> i.e. replace...
>
>   PROCEDURE check0();
>     BEGIN p0 := p1;
>     CASE p0 OF
>       P1:
>         AssignGlobal();
>         p0*(P1)*.fld1 := 123;
>     END
>   END check0;
>
> with...
>
>   PROCEDURE check0();
>     BEGIN p0 := p1;
>     IF p0 IS P1 THEN
>         AssignGlobal();
>         p0*(P1)*.fld1 := 123;
>     END
>   END check0;
>
> My (proposed) solution rescues the CASE statement (which is efficient
> relative
> to IF x IS T + series of additional type tests inside the IF statement),
> while at
> the same time solving its type loophole issues.
>
> But I would not mind eliminating the type case statement and just have
> type guards.
>
> -ap
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201030/780c3a2f/attachment.html>