Created attachment 65604 [details]
Patch for this issue

Created attachment 65607 [details]
Test case sample file for this issue

Created attachment 65746 [details]
Patch for this issue

problem:
omitted optional paramaters of rtl functions are incorrectly handled

minimal test to demonstrate problem

sub tester
dim str as string
str = "find for replace"
result = Replace(str, "find", "replace", , 0)
if result <> str then msgbox "fail"
end sub

what's wrong

result is returned as a zero length string

why does it happen

the fourth parameter is ommitted, the basic runtime has set the optional param
with an error value ( in StepMISSING ), this results in the 'Replace'
implementation code thinking the 4th parameter has been supplied and is
getting an incorrect value ( 448 ) and so generates an incorrect result.

The patch supplied above seems too invasive, this would seem to be a general
problem, its possible perhaps the test in the RTL implementation for ommitted
optional parameters is incorrect. I will look some more into this

->ab in the meantime if you have any info Andreas please pass it on ;-)

solution, change the StepMISSING to do.....

Hope you can see how helpful a description like the above is to someone
who is trying to see review the patch

first StepMISSING actually doesn't exist I meant StepEMPTY ( confusion with the
comments and thoughts about a solution )

I looked a bit more into this, we could solve this by changing the existing test
to see if the parameter has the error ( with the magic number set ) but this
seems to be a very awkward test. 
It seems to me that either
a) stepEMPTY shouldn't set the error But I am presuming that stepEMPTY sets that
error because the compilier doesn't seem to take into account optional
parameters in the RTL functions. ( andreas hope you have some idea about that )
Anyway just blindly removing the error doesn't seem to be the correct thing to
do imo
b) or maybe stepEMPTY shouldn't be emitted in this case but say a new OP code
e.g. stepMISSING ( for the case of optional params ) but... I guess the compiler
would need to be smarter ( and it doesn't look like SbiExprNode or SbiExprList
have that context )
c) I guess a third solution would be to resolve this at runtime, iirc
SbiRuntime::SetupArgs already does some post processing, in here we could see
what parameters have been 'ommitted' and for those parameters that really are
optional and missing ( e.g. have the 'magic' error ) those parameters could
really be made 'EMPTY' 

what do you think?

->ab for expert opinion

Created attachment 66039 [details]
patch file to fix this issue

patch attached reflects changing Stepargs which seems like the simplist and
cleanest way to fix this ( not tested fully :-/ note: most of the diffs are
whitespace changes ) 
thoughts?

noel, I tested, your patch works well for my case.

STARTED, -> PATCH, OOo 3.x

-> cws ab75

I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:  dev@openoffice.apache.org

Thanks!

-Rob

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