[
https://issues.apache.org/jira/browse/THRIFT-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731885#comment-14731885
]
Nobuaki Sukegawa commented on THRIFT-3302:
------------------------------------------
[~jensg], yes, casting in generated code then casting back in protocols is
awkward and a little hacky.
I updated the pull request to change the signature.
Both {{make check}} and {{make cross}} should run fine with this.
Note that I only changed signatures of protocol API, but not ones of transport
API because
* The knowledge of Thrift byte type is specific to protocols. Transports does
not necessarily need to know it.
* Many Go standard lib types used in transports have {{Read/WriteByte(byte)}}
so we cannot completely unify the signature anyway.
> Go JSON protocol should encode Thrift byte type as signed integer string
> ------------------------------------------------------------------------
>
> Key: THRIFT-3302
> URL: https://issues.apache.org/jira/browse/THRIFT-3302
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
> Reporter: Nobuaki Sukegawa
> Assignee: Nobuaki Sukegawa
>
> h3. Problem
> Go implementation of JSON and simple JSON protocols encode Thrift byte type
> field as unsigned 8bit integer.
> i.e. -1 is encoded to "255" by Go implementation while "-1" by others like
> C++, Java and Python.
> h3. Reproduce
> Cross test with go server and py client (JSON protocols of course).
> (like "expected -127 but got 129")
> Static-typed clients (such as C++ and Java) are not likely to notice the
> difference because of integer overflow.
> h3. Fix
> Explicitly convert the unsigned 8-bit value back to signed one in JSON
> protocols before converting to text.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
