Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Basic interpreter doesn't check missing parentheses|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Version:||OOo 1.1 Beta2|
|Target Milestone:||AOO PleaseHelp|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description paolomantovani 2003-08-02 00:13:20 UTC
REM ***** BASIC ***** 'the code below shows that 'missing parentheses doesn't 'causes any compilation errors '(as they should, of course) Option Explicit Sub ParenthesesBug1 Dim mList(2) As String mList(0 = "ciao" 'no errors here!! Print Typename(mList( 'no errors here!! End Sub
Comment 1 paolomantovani 2003-08-02 01:34:07 UTC
*** Issue 17782 has been marked as a duplicate of this issue. ***
Comment 2 kay.ramme 2003-08-04 12:08:41 UTC
Andreas, please take of this and set the target accordingly (OOo2.0)?
Comment 3 ab 2003-09-01 14:18:16 UTC
-> OOo 2.0
Comment 4 Martin Hollmichel 2004-05-28 17:36:57 UTC
according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later.
Comment 5 ab 2005-08-18 13:17:17 UTC
To fix this would be critical because old programs containing wrong parentheses could be broken. Could only be fixed in the scope of a "strict" mode.
Comment 6 paolomantovani 2005-08-19 18:37:40 UTC
IMHO a fix in the scope of a "strict" mode (I think you have in mind some switch like the OptionCompatible mode) would not make much sense here. I appreciate the extreme caution in order to preserve compatibility with existing basic code, but here we are speaking of existing _incorrect_ code. BTW I would let you know that I can remember at least two or three cases where an enhancement or fix in the basic engine caused me (and maybe other) to change my code to get it working in the new version. :-) I mean perfectly correct basic code that in the switch from 1.0.x to 1.1.x has been broken. And, at least in one case, I'm not speaking of simply add a missing parenthesis, but to rewrite a whole module, after a complicated debugging. ...I'm not joking, it's true :-) So, it seems to me that not fixing a bug in order to preserve compatibility with existing incorrect code is even too much caution. I think that if one writes incorrect code, the problem is on his own side, independently from the behavior of the interpreter. Anyway, I don't want to bother furthermore on this matter, so I will appreciate any decision you will take. best regards Paolo
Comment 7 ab 2005-08-22 08:25:01 UTC
I'm sorry to hear that you had to rewrite a module. That's what I always want to avoid but obviously that hasn't been successfull in all cases. BTW: If you had to change correct code to make it run in 1.1 it means that 1.1 contained a re- gression bug. Do you know if this problem is still there? If Basic does not run correct code, it's simply a bug. In any case this of course happened accidentally and I don't think this mistake is appropriate to justify breaking existing code in general. Of course, you're right that breaking incorrect code is not as bad as breaking correct code but I think there are different levels of incorrect code. If I take advantage of an ob- vious bug in my program I can't complain when the bug is fixed. But forgetting a parentheses can be done accidentally, in particular if the compiler does not complain about it... ;-) Ok, now we're going round in circles, but that's why I would prefer a "strict" mode. But this should be a general option that you only have to set once, not in every module.
Comment 8 paolomantovani 2005-08-22 14:46:50 UTC
AB> I'm sorry to hear that you had to rewrite a module. np :-) I have reported this only for completeness, not for complaining. Anyway, IMHO the problem I reported it was not a regression and not a bug, only a new (useful) feature with some side effects: But let me better explain the thing: The package I'm speaking is "Basic Macro Recorder" , a simple macro recorder for Calc, fully implemented in Basic and based on listeners. Somewhere between 1.0 and 1.1 you've introduced the "recursivity", that is the ability of a function or sub to call itself. A side effect of this ability is that a listener can execute an event routine before the previous execution has finished. In opposition, before the introduction of recursivity, if a listener did the call before the previous one had finished, the call was simply lost. In other words, now you can have 2 or more copies of the same routine running at the same time. This is not a problem except in case the event handler routine has to deal with global data. In this case you may have typical problems of thread-programming (race conditions, global data inconsistencies, etc.) Once I had recognized the problem, I solved implementing something near to a semaphore. It was not so easy, but it was very enjoying an instructive :-) best regards Paolo