[
https://issues.apache.org/jira/browse/AXIS2C-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561596#action_12561596
]
S.Uthaiyashankar commented on AXIS2C-866:
-----------------------------------------
we have two implementations to decode. They are axutil_base64_decode and
axutil_base64_decode_binary. To create buffer for axutil_base64_decode we need
"length + 1" where "length" is the actual decoded length. This is because,
axutil_base64_decode appends a null character at the end of the buffer. Hence
the +1 in axutil_base64_decode_len.
Option 1: One possible way to overcome this is to have two functions to return
the length, namely axutil_base64_decode_len and
axutil_base64_decode_binary_len, where axutil_base64_decode_len returns
axutil_base64_decode_binary_len + 1. Disadvantage of this is, we have to modify
lots of places since axutil_base64_decode_binary is used in lots of places.
(axutil_base64_decode is used only in some places in rampart. It is not used in
axis2c. Not sure whether other modules use it).
Option 2: Other option is moving +1 part to the code itself. So, if anybody
needs to use axutil_base64_decode, then they have to create the buffer with
size (axutil_base64_decode_len + 1). Disadvantage is, we might forget this fact
in future :-(.
Option 3: If we can find another function name, which can be linked to
axutil_base64_decode, then we can use the function axutil_base64_decode_len
linked to axutil_base64_decode_binary. (possibly
axutil_base64_decode_nonbinary_len :-) ). In this case, the modifications will
be minimum.
Option 4: since, axutil_base64_decode_binary covers the requirement of
axutil_base64_decode, we can remove the method axutil_base64_decode. Since
decoded buffer can be non printable characters, is it advantage to add a null
character at the end and getting a buffer?? (call to axutil_base64_decode can
be changed to axutil_base64_decode_binary in rampart).
which option would be better??
> REOPEN - /util/src/base64.c incorrect calculation of length in
> 'axutil_base64_decode_len'
> -----------------------------------------------------------------------------------------
>
> Key: AXIS2C-866
> URL: https://issues.apache.org/jira/browse/AXIS2C-866
> Project: Axis2-C
> Issue Type: Bug
> Components: util
> Affects Versions: 1.2.0
> Reporter: Frank Huebbers
> Priority: Critical
>
> Hi,
> First off, I am opening a new issue here because I don't seem to be able to
> reopen case AXIS2C-731 which does not yet seem to be fixed either for the
> release candidate 1.2.0 (Take 4) nor on head.
> Specifically, it appears as if the proposed bug fix in AXIS2C-731 did not
> make it 1-to-1 into CVS. To reiterate, the proposed bug fix was:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded;
> }
> What actually made it into 1.2.0 and head is the following:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded + 1;
> }
> => Note the "+1" on the return type.
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
