[ https://issues.apache.org/jira/browse/THRIFT-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662311#comment-13662311 ]
Eric Ding commented on THRIFT-1973: ----------------------------------- Yeah, I tested this using the test client and server project in the C# lib. I didn't run with another server in a different language. Are you saying that a C# client and C++ server, this works correctly? Looking at the code in C++ and Java, zigzag functions are correct. But paired with C# client, they should failed. I didn't add any new test cases in the test project because it already has it. I just switched the protocol from Binary to Compact. And the test cases already in the test project failed for negative numbers on server vs what was sent from the client. The thing I did notice is that the client test calls send and receive to verify the number. In this particular case, the client receives the same number back. But the server actually receives a different number. The code needs to run ones complement once for serialize and once for deserialize it. Calling sending and receiving just happens to deserialize correctly again on the client. > TCompactProtocol in C# lib does not serialize and deserialize negative int32 > and int64 number correctly > ------------------------------------------------------------------------------------------------------- > > Key: THRIFT-1973 > URL: https://issues.apache.org/jira/browse/THRIFT-1973 > Project: Thrift > Issue Type: Bug > Components: C# - Library > Affects Versions: 0.9, 1.0 > Environment: Windows > Reporter: Eric Ding > Labels: PatchAvailable > Fix For: 1.0 > > Attachments: thrift-1973-TCompactProtocol-Fix.patch > > > longToZigzag and ZigzagToLong in TCompactProtocol does not perform > corresponding operations to serialize and deserialize negative int32 and > int64 number correctly. Purpose to change longToZigzag from > (ulong)(((ulong)n << 1) ^ ((ulong)n >> 63)) to (ulong)(n << 1) ^ (ulong)(n >> > 63). > Will need to do same for intToZigZag. The reason is that we want arithmetic > shift not logic shift. > The test case in the project shows this, the output on server and client are > different even though client received the same number back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira