[
https://issues.apache.org/jira/browse/AXIS2C-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608272#action_12608272
]
Supun Kamburugamuva commented on AXIS2C-976:
--------------------------------------------
This is an API method. We cannot change an API method without effecting the
backward compatibility. There may be people who are using this method. One
option may be to introduce a new method with your suggestion. May be we can
depreciate this method and introduce a new method. But apart from this
convention problem I don't see any other reason for depreciating this method.
Simply this is the way we do this. If users are happy with that, we can live
with what we have.
Supun..
> 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]
