It seems I found a bug... :(

[AVC 0]

I like Oberon-2 very much, and especially I like XDS compiler.

But it seems I have found a bug in it.

More exactly - in FOR cycle.

Here it is:

<* +MAIN *>

MODULE XdsBugInFor;

 VAR a: ARRAY MAX(INTEGER)+2 OF INTEGER;

     

 PROCEDURE CauseRunTimeError(VAR a: ARRAY OF INTEGER);

   VAR i: INTEGER;

 BEGIN (* I believe it is to be a compilation-time error, not run-time one! *)

   FOR i := 0 TO LEN(a)-1 DO

     a := 0

   END

 END CauseRunTimeError;

     

BEGIN

 CauseRunTimeError(a)

END XdsBugInFor.

According to Oakwood guidelines:

The statement

 FOR v := beg TO end BY step DO statements END

is equivalent to

 temp := end; v := beg;

 IF step > 0 THEN

   WHILE v <= temp DO statements; v := v + step END

 ELSE

   WHILE v >= temp DO statements; v := v + step END

 END

temp has the same type as v. step must be a nonzero constant expression.

If step is not specified, it is assumed to be 1.

Please note that "temp has the same type as v".

It means that in procedure CauseRunTimeError it has type INTEGER (INT16).

But LEN(a) has type LONGINT (INT32).

So I think that no Oberon compiler should let the assignment

     temp := LEN(a) - 1

without explicit SHORT conversion.

I wonder whether I am right or wrong, because even in Wirth's book

"Programming in Oberon" I have found such an "incorrect" example:

PROCEDURE sum(VAR x: ARRAY OF REAL): REAL;

     VAR i: INTEGER; s: REAL;

BEGIN s := 0.0;

     FOR i := 0 TO LEN(x)-1 DO s := x + s END ;

     RETURN s

END sum;

It may look a "puzzle" for a beginner, because the variable "temp" is hidden

(in my case it is placed in the register EDX), and XDS debugger does not

show it in Locals' window.

[Vit 0]

You're probably right that it is one of those noone-thought-about things.

As for XDS O2, it was merely done following N.Wirth's book, not Oakwoods recommendations, hence the semantics you mentioned has not been checked probably.

However, the case is checked, though at run time.

[AVC 0]

Thank you for reply!

Is it possible that the situation will be fixed in a future release?

Otherwise there may be some strange situations when two nearly identical lines of code behave differently.

One causes a compiler error, the other does not.

For example:

<* +MAIN *>

MODULE For;

     VAR a: ARRAY MAX(INTEGER)+2 OF INTEGER;

     

     PROCEDURE TestFOR(VAR a: ARRAY OF INTEGER);

           VAR i: INTEGER;

     BEGIN

           FOR i := 0 TO LEN(a)-1 DO a := 0 END;

           FOR i := LEN(a)-1 TO 0 BY -1 DO a := 0 END;

     END TestFOR;

BEGIN

     TestFOR(a)

END For.

It seems to be strange that the second FOR is considered to be

a compile error but the first is not.

[snowman 0]

Is it possible that the situation will be fixed in a future release?

We have added this issue to our tracking system. If a paying customer asks to fix it, or the whole project gets sponsored, it will be fixed.

[wilbertnl 0]

If a paying customer asks to fix it, or the whole project gets sponsored, it will be fixed.

So, did someone estimate the cost price for this fix?

[Vit 0]

Not yet. We'll do it on request.

Fixing a particular bug or feature may take not much time for itself. We spend more on testing and releasing.

Vit