DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18907>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18907 Invalid XML Character in output [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2003-08-13 05:59 ------- Patch has just been applied to main branch of CVS. The re-work was to make ToStream.writeUTF16Surrogate(char c, char ch[], int i, int end) return nothing rather than the "i+1" that it always returned, which was a bit confusing. This routine always processed 2 input characters and always returned "i+1" so why bother? There was no error in returning "i+1" because the situation in which this routine was called were always in a loop: for (int i=start; i < end; i++) { ... } so "i" was always incremented before going on to the next iteration. Any i++; after calling writeUTF16Surrogate() now means that 2 input characters have been processed, so there is no bug here (never was). The code is just clearer now. A bug has been fixed in ToStream.accumDefaultEscape() which used to mis-count how many input characters that it processed. It may still be possible that two character() calls on the serializer split a UTF-16 pair across the calls, but this one is being ignored for now. All the older code has always thrown exceptions if it expected a UTF-16 surrogate pair, but ran in the end of the array too soon. - Brian Minchau
