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=5326>. 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=5326 bugs in Base64::encode and Base64::decode Summary: bugs in Base64::encode and Base64::decode Product: Xerces-C++ Version: 1.5.2 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I found the bugs in version 1.5.2 and see that they have not been fixed in newly released version 1.6. The platform is Intel/Windows2K/VC6, but I believe these bugs occur in other platforms as well. 1. Function base64::encode - In processing the last input quadruplet, if there's one octet left, the function forgot to put the second encoded octet before padding. This bug could lead to encoded data even cannot be decoded!!! The original code is: // process the last Quadruplet // first octet is present always, process it split1stOctet( inputData[ inputIndex++ ], b1, b2 ); encodedData[ outputIndex++ ] = base64Alphabet[ b1 ]; if( inputIndex < inputLength ) { ......... } else { // second octet not present, b2 is all we got // two PADs e.g. 3c== encodedData[ outputIndex++ ] = base64Padding; encodedData[ outputIndex++ ] = base64Padding; } The function did not output b2. Fixed code would be: else { // second octet not present, b2 is all we got encodedData[ outputIndex++ ] = base64Alphabet[ b2 ]; //ADDED LINE HERE // two PADs e.g. 3c== encodedData[ outputIndex++ ] = base64Padding; encodedData[ outputIndex++ ] = base64Padding; } 2. Function Base64::decode The function uses 3 inline functions: set1stOctet, set2ndOctet, set3rdOctet, of which I found set2ndOctet and set3rdOctet not correct. The original code: inline XMLCh Base64::set2ndOctet(const XMLCh& b2, const XMLCh& b3) { return (( b2 << 4 ) | ( b3 >> 2 )); } inline XMLCh Base64::set3rdOctet(const XMLCh& b3, const XMLCh& b4) { return ( ( b3 << 6 ) | b4 ); } The point is we are processing XMLCh, which is 2-byte wide. So the left- shifting could make the higher bits in the low byte move to the high byte. We must clear those higher bits before left-shifting. So the fixed code would be: inline XMLCh Base64::set2ndOctet(const XMLCh& b2, const XMLCh& b3) { return (( (b2 & 0xf) << 4 ) | ( b3 >> 2 )); } inline XMLCh Base64::set3rdOctet(const XMLCh& b3, const XMLCh& b4) { return (( (b3 & 0x3) << 6 ) | b4 ); } Correct me if I'm wrong. Pham Kim Long --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
