Issue 17781

Summary:	Basic interpreter doesn't check missing parentheses
Product:	udk	Reporter:	paolomantovani <p_manto>
Component:	code	Assignee:	AOO issues mailing list <issues>
Status:	ACCEPTED ---	QA Contact:
Severity:	Trivial
Priority:	P4	CC:	issues, maison.godard
Version:	OOo 1.1 Beta2
Target Milestone:	AOO PleaseHelp
Hardware:	All
OS:	All
Issue Type:	DEFECT	Latest Confirmation in:	---
Developer Difficulty:	---

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

Comment 9 Marcus 2017-05-20 11:29:23 UTC

Reset assigne to the default "issues@openoffice.apache.org".