[ https://issues.apache.org/jira/browse/THRIFT-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731886#comment-14731886 ]
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)