Bug in java.lang.StringBuffer append(char[])?
Hi all,
Sorry if this is a known issue, but both a Google and a Parallax site search didn't turn up anything. The implementation of StringBuffer append(char str[noparse]/noparse, int length) that ships with the 2.03 Javelin Stamp IDE is a bit strange, and in my opinion incorrect.
The loop that copies characters from the input array to the internal array holding the StringBuffer does this (please note that the * in [noparse][[/noparse]i*] is just there to prevent the forum software from misinterpreting it as an italics tag...):
...which means that invoking this method on a non-empty StringBuffer will pretty much always have unexpected results. Consider the case where you're trying to append 2 chars to a StringBuffer that already holds 4: i will be initialized to 4, causing the loop to exit immediately, and the StringBuffer to remain unchanged.
If the loop is changed to either
or
the result is as expected/documented.
Since 'real Java' doesn't have this particular version of the append method, I can't be 100% sure the original behavior isn't as intended, but it seems unlikely.
And, while we're at it, what is the trick to set breakpoints in the 2.03 IDE? Debug/Breakpoint doesn't seem to do anything, whether the debugger is already running or not...
'//mdb
Sorry if this is a known issue, but both a Google and a Parallax site search didn't turn up anything. The implementation of StringBuffer append(char str[noparse]/noparse, int length) that ships with the 2.03 Javelin Stamp IDE is a bit strange, and in my opinion incorrect.
The loop that copies characters from the input array to the internal array holding the StringBuffer does this (please note that the * in [noparse][[/noparse]i*] is just there to prevent the forum software from misinterpreting it as an italics tag...):
for ( int i = this.length; i < length; i++ )
s[noparse][[/noparse]i*] = str[noparse][[/noparse]i-this.length];
...which means that invoking this method on a non-empty StringBuffer will pretty much always have unexpected results. Consider the case where you're trying to append 2 chars to a StringBuffer that already holds 4: i will be initialized to 4, causing the loop to exit immediately, and the StringBuffer to remain unchanged.
If the loop is changed to either
for (int i = 0; i < length; i++)
s[noparse][[/noparse]i+this.length] = str[noparse][[/noparse]i*];
or
for (int i = this.length; i < this.length+length; i++)
s[noparse][[/noparse]i*] = str[noparse][[/noparse]i-this.length];
the result is as expected/documented.
Since 'real Java' doesn't have this particular version of the append method, I can't be 100% sure the original behavior isn't as intended, but it seems unlikely.
And, while we're at it, what is the trick to set breakpoints in the 2.03 IDE? Debug/Breakpoint doesn't seem to do anything, whether the debugger is already running or not...
'//mdb
Comments
Here is the original (current) version.
· /**
·· * Append an array of characters to a StringBuffer.
·· *
·· * @param str the array to append.
·· * @param length the number of characters from str to append.
·· * @return the StringBuffer.
·· */
· public StringBuffer append(char str[noparse]/noparse, int length) {
··· expand(length);
··· for ( int i = this.length; i < length; i++ )
····· s[noparse][[/noparse]i] = str[noparse][[/noparse]i-this.length];
··· this.length += length;
··· return this;
· }
By using this.length there is even more code than really required.
Here is a corrected and optimized version.
· /**
·· * Append an array of characters to a StringBuffer.
·· *
·· * @param str the array to append.
·· * @param length the number of characters from str to append.
·· * @return the StringBuffer.
·· */
· public StringBuffer append(char str[noparse]/noparse, int length) {
··· expand(length);
··· for ( int i = 0; i < length; i++ )
····· s[noparse][[/noparse]this.length++] = str[noparse][[/noparse]i];
····return this;
· }
regards peter
And while on the subject of java.lang.StringBuffer: adding something like the code below is also quite helpful, in that statements like System.out.println("Reset result: "+e.reset()); (where e returns a boolean) no longer cause a fatal linker error:
/** * Append the textual representation of a boolean to the StringBuffer. * * @param b the boolean to append. * @param the StringBuffer. */ public StringBuffer append(boolean b) { if(b) { return this.append("true"); } else { return this.append("false"); } }
'//mdb
http://groups.yahoo.com/group/JavelinCode/files/Javelin%20Stamp%20IDE/lib/java/lang/
Note there is also an updated String class there.
This one had a bug in IndexOf method.
That bug was also present in StringBuffer.
So StringBuffer has two bugfixes.
regards peter
·