[
https://issues.apache.org/jira/browse/PROTON-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949577#comment-15949577
]
ASF GitHub Bot commented on PROTON-1453:
----------------------------------------
Github user alanconway commented on the issue:
https://github.com/apache/qpid-proton/pull/101
Disagree. IMO it is good design for all return values of a failing call to
be set to known failure indicators provided a) there are such indicators, b)
it is not costly to do so, and c) it is unlikely there was valuable data in
them before call. Provided the API doc is clear that the value will always be
set (to "" in an error) that seems to me more robust than leaving random data
lying around.
I agree the tests are poorly written for not checking the return value but
I think the more robust behavior leads to less support calls.
> pn_ssl_get_{protocol|cypher}_name() may segfault when called by bindings
> ------------------------------------------------------------------------
>
> Key: PROTON-1453
> URL: https://issues.apache.org/jira/browse/PROTON-1453
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.17.0
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Fix For: 0.18.0
>
>
> the pn_ssl_get_password/cipher_name method takes a target buffer and length
> and if the name is known it is copied to the buffer (null terminated) and
> true is returned.
> However if the name is not known (not yet present) the method returns false
> and leaves the buffer untouched.
> This is fine for correctly behaving C programs, but the swig generated code
> always assumes the output buffer contains a properly terminated string
> whether or not the return value is true. The swigged code unconditionally
> calls strlen() on the returned buffer.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
