[
https://issues.apache.org/jira/browse/AXIS2C-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608306#action_12608306
]
Senaka Fernando commented on AXIS2C-976:
----------------------------------------
Well this is not a question about backward compatibility. We have done this
wrong. Anyway, we will need to see where it is being used, and if it has any
potential use beyond the scope of axis2c or its subprojects we will have to fix
this at a 2.0 perhaps. It does not suffice to create an alternate to this.
That's a hack according to my belief.
Please also check into the way the base64 decode length is returned. So if the
encode/decode length is specified in a similar manner we need not perhaps
correct this at all.
Regards,
Senaka
> base64 encode length returns size of encoded string + 1.
> --------------------------------------------------------
>
> Key: AXIS2C-976
> URL: https://issues.apache.org/jira/browse/AXIS2C-976
> Project: Axis2-C
> Issue Type: Bug
> Affects Versions: 1.3.0
> Reporter: Senaka Fernando
> Assignee: S.Uthaiyashankar
>
> base64 encode length returns size of encoded string + 1, which is incorrect.
> This is because we assume that someone expects the length + 1 to accommodate
> '\0' that we add. But, if we gave the same string to a strlen() it returns
> size of encoded string. This would confuse a potential user.
> axutil_base64_encode (encoded, "senaka", 6) = 9, and strlen(encoded) = 8.
> Also, axutil_base64_encode_len(6) = 9.
> Therefore, I think it is better to stick to the strlen() way, especially
> because popular libraries and resources adopt that strategy. Refer [1] for
> more information.
> [1] http://www.obviex.com/Articles/CiphertextSize.aspx
> Regards,
> Senaka
--
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]
