Page 1 of 2
issue-#16: TRAP in DevAnalyzer.UseObj
Posted: Fri Jul 18, 2014 5:40 am
by Ivan Denisov
Let's discuss the alternative solutions and vote for including this bug fix?
http://redmine.blackboxframework.org/issues/7
Re: #7 TRAP in DevAnalyzer.UseObj
Posted: Sun Sep 28, 2014 4:23 pm
by Ivan Denisov
Can you please, evaluate my solution of this bug?
Re: #7 TRAP in DevAnalyzer.UseObj
Posted: Sun Sep 28, 2014 9:59 pm
by cfbsoftware
The example provided is true garbage code. The fact that the analyser traps on it does not surprise or concern me greatly - if it does happen it might be a good incentive for the programmer to take more care in future. If it only traps on the sort of example provided I would hope that it occurs in real-life extremely rarely.
However, if you believe it is worthy of more attention, please provide a description of the precise nature / scope of the problem, what alternative solutions there are and why you prefer your proposed solution.
Re: #7 TRAP in DevAnalyzer.UseObj
Posted: Mon Sep 29, 2014 6:39 am
by Ivan Denisov
I had catch this error when I forgot to change index number and run Analyzer. You are right that it is good indicator if something wrong. However the language report does not prohibit such code and compiler do it well. Analyzer can indicate this, but not with TRAP. I will think about alternative fix with warning message for user.
Re: #7 TRAP in DevAnalyzer.UseObj
Posted: Mon Sep 29, 2014 7:50 am
by Josef Templ
This bug needs to be analyzed more carefully.
The fix proposed by Ivan does not solve all problems.
Look for example at the following test case:
Code: Select all
FOR i := 0 TO 100 DO
FOR i := 0 TO 100 DO
FOR i := 0 TO 100 DO
b := i
END;
b := i
END
END
There is a tricky encoding of obj.num being used for nested FOR loops.
We must understand that trick first before we can solve the problem.
- Josef
Re: #7 TRAP in DevAnalyzer.UseObj
Posted: Mon Sep 29, 2014 8:50 am
by Josef Templ
A similar bug fix must also be applied in SetObj and it
may be slightly simplified in UseObj as outlined below.
Code: Select all
| set: obj.num := setUsed
ELSE (* already marked as being used *)
END
END
END UseObj;
Code: Select all
| set: IF varPar THEN obj.num := setUsed END
ELSE DumpObj(obj); err2(loopVarSet, pos) (* for loop variable gets set!*)
END
END
END SetObj;
- Josef
Re: #7 TRAP in DevAnalyzer.UseObj
Posted: Mon Sep 29, 2014 9:42 am
by Josef Templ
I have just seen that this bug is already covered by the CPC 1.7 change list
as number 44. The proposed fix in CPC 1.7 does not include the above
simplification and suppresses errors in SetObj for deeper nesting levels
because it uses an empty ELSE branch.
So, I believe that the above proposal is superior.
I have created
issue #16 in redmine for it and I have created a
topic branch
issue-#16 with the above changes.
- Josef
Re: #7 → #16 TRAP in DevAnalyzer.UseObj
Posted: Fri Oct 03, 2014 6:53 pm
by Ivan Denisov
Josef and Helmut, thank you for this work!
It works perfect:
- forLoop.png (7.02 KiB) Viewed 12074 times
For all members, you can try this here:
http://blackboxframework.org/unstable/i ... a1.010.zip
The differences in sources you can see following this link:
http://redmine.blackboxframework.org/pr ... 91b914d590
I think, that we can vote for including this in Center version? Or we need some further discussion?
Re: #7 → #16 TRAP in DevAnalyzer.UseObj
Posted: Fri Oct 03, 2014 11:59 pm
by DGDanforth
I just have a question about issue priority.
Are we chipping away at issues stated by Helmut/OberonCore or do we have a
systematic program for incorporating them in our next version?
Our #16 looks like we have cherry picked one of their issues (44).
-Doug
Re: #7 → #16 TRAP in DevAnalyzer.UseObj
Posted: Sat Oct 04, 2014 8:13 am
by Josef Templ
DGDanforth wrote:I just have a question about issue priority.
Are we chipping away at issues stated by Helmut/OberonCore or do we have a
systematic program for incorporating them in our next version?
Our #16 looks like we have cherry picked one of their issues (44).
-Doug
The issues I have entered so far in the issue tracker are all related in some sense with
the automated build process (#14). The DevAnalyzer bug is a bit out of order in that sense.
However, as long as there are no merge conflicts to expect, I don't really mind about the order.
When we are eventually going to attack the Unicode in CP identifiers issue,
we must be careful not to introduce a lot of merge conflicts with other topics.
Therefore the Unicode issue MUST be the only one to be worked on until it is merged to master.
Manual merges are not only tedious but also a potential source of errors.
- Josef