You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by bu...@apache.org on 2002/02/08 16:13:45 UTC
DO NOT REPLY [Bug 6330] New: -
Base64::encode does not work
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=6330>.
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=6330
Base64::encode does not work
Summary: Base64::encode does not work
Product: Xerces-C++
Version: 1.6.0
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Critical
Priority: Other
Component: Utilities
AssignedTo: xerces-c-dev@xml.apache.org
ReportedBy: nberntsen@visionik.com
CC: nberntsen@visionik.com
at Base64.cpp:157
split1stOctet( inputData[ inputIndex++ ], b1, b2 );
can return "wild" values for b1 (and the b2, as can the other slit*Octet).
b1 (and others) are used at Base64.cpp:162 ++
encodedData[ outputIndex++ ] = base64Alphabet[ b1 ];
where they provide out-of range values for encodedDaat.
The problem is with the definition of the slit*Octet functions:
inline void Base64::split1stOctet(const XMLCh& ch, XMLCh& b1, XMLCh& b2) {
b1 = ch >> 2;
b2 = ( ch & 0x3 ) << 4;
}
Which takes an XMLCh 16 Bit value (at least, that is what they are on the
SUN,Solaris) and hope to get a 6 bit value by a two bit shift operation. It is
probably the right thing to do with 8bit chars.
I believe that XMLCh is alway UTF-16, which means that one should
probably work on char's instead.
Regards
Nikolaj
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 6330] New: - Base64::encode does not work
Posted by PeiYong PY Zhang <pe...@ca.ibm.com>.
Nikolaj,
The patch to the problem mentioned shall be available from the next nightly
build,
please help to test if it works on your SUN platform, thanks.
Rgds,
PeiYong
bugzilla@apache.org wrote:
> 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=6330>.
> 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=6330
>
> Base64::encode does not work
>
> Summary: Base64::encode does not work
> Product: Xerces-C++
> Version: 1.6.0
> Platform: Sun
> OS/Version: Solaris
> Status: NEW
> Severity: Critical
> Priority: Other
> Component: Utilities
> AssignedTo: xerces-c-dev@xml.apache.org
> ReportedBy: nberntsen@visionik.com
> CC: nberntsen@visionik.com
>
> at Base64.cpp:157
> split1stOctet( inputData[ inputIndex++ ], b1, b2 );
> can return "wild" values for b1 (and the b2, as can the other slit*Octet).
>
> b1 (and others) are used at Base64.cpp:162 ++
>
> encodedData[ outputIndex++ ] = base64Alphabet[ b1 ];
>
> where they provide out-of range values for encodedDaat.
>
> The problem is with the definition of the slit*Octet functions:
>
> inline void Base64::split1stOctet(const XMLCh& ch, XMLCh& b1, XMLCh& b2) {
> b1 = ch >> 2;
> b2 = ( ch & 0x3 ) << 4;
> }
>
> Which takes an XMLCh 16 Bit value (at least, that is what they are on the
> SUN,Solaris) and hope to get a 6 bit value by a two bit shift operation. It is
> probably the right thing to do with 8bit chars.
>
> I believe that XMLCh is alway UTF-16, which means that one should
> probably work on char's instead.
>
> Regards
> Nikolaj
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org