AVC 0 Report post Posted June 10, 2005 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. Share this post Link to post Share on other sites
Vit 0 Report post Posted June 10, 2005 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. Share this post Link to post Share on other sites
AVC 0 Report post Posted June 11, 2005 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. Share this post Link to post Share on other sites
snowman 0 Report post Posted June 11, 2005 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. Share this post Link to post Share on other sites
wilbertnl 0 Report post Posted June 15, 2005 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? Share this post Link to post Share on other sites
Vit 0 Report post Posted June 16, 2005 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 Share this post Link to post Share on other sites