[
https://issues.apache.org/jira/browse/THRIFT-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17855400#comment-17855400
]
Team_RPCtester commented on THRIFT-5791:
----------------------------------------
Thank you for your help. Is this the way to declare it with the constructor
generated by thrift compiler? By following this method, the Go code sets
{{f_4}} to 23 without any inconsistency.
uitem_def := &commonResource.Union_0{Uitem_2: thrift.StringPtr("lZz")}
structArg := commonResource.NewStructClass_0()
structArg.F_1=26570
structArg.F_2 = "2XT"
structArg.F_3 = uitem_def
The method we previously demonstrated also works (i.e., it can successfully
send messages to others, except for setting the default value to 0). We have
observed others using the same approach without using the constructor generated
by the Thrift compiler, for example, in [osquery-go/client.go at
61ac79279aaa3e119940707816ba90c3dd5c5cb3 · osquery/osquery-go
(github.com)|https://github.com/osquery/osquery-go/blob/61ac79279aaa3e119940707816ba90c3dd5c5cb3/client.go#L139]
).
uitem_def := &commonResource.Union_0{Uitem_2: thrift.StringPtr("lZz")}
structArg := &commonResource.StructClass_0{F_1: 26570, F_2: "bJY", F_3:
uitem_def}
Could this be considered an unexpected behavior? And should it be addressed as
a bug fix? If you plan to resolve this issue, we would be happy to assist with
testing. Sincerely thank you for your help.
> Inconsistent behavior: Go does not use default values
> -----------------------------------------------------
>
> Key: THRIFT-5791
> URL: https://issues.apache.org/jira/browse/THRIFT-5791
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler, Go - Library
> Affects Versions: 0.19.0, 0.20.0
> Reporter: Team_RPCtester
> Priority: Major
> Attachments: image-2024-06-02-20-15-37-106.png,
> image-2024-06-02-20-15-55-606.png, image-2024-06-02-20-16-08-144.png,
> image-2024-06-14-21-43-51-655.png, image-2024-06-14-21-45-17-915.png,
> submit_thrift.zip, temp_thrift.zip
>
>
> Hi,
> We are software engineering researchers working on automated program analysis
> techniques to improve the reliability of RPC frameworks.
>
> We discover a bug illustrated by the following example (The attached script
> can help you reproduce the issue).
> When using a .thrift file to define a struct, if one of the fields is
> optional and has a default i8 value (e.g., 73), there is an inconsistent
> behavior in implementations across different languages. Specifically:
> # In the Go implementation, if the field is not explicitly defined or
> assigned a value, the transmitted value is 0.
> # In the Python and Node.js implementations, if the field is not explicitly
> defined or assigned a value, the transmitted value is the default value of 73.
> This inconsistency indicates that there might be an issue with the Go
> implementation.
> In our setting, we use Go, Node.js, and Python 3 as the server side, and use
> Go, Node.js, and Python 3, as the client side. The thrift file we use is
> shown in the flowing picture:
> !image-2024-06-02-20-15-37-106.png!
> When calling Method_3, the message passed is an instance of StructClass_0,
> where f_4 is not set. The f_4 is automatically defined as 0, while in Python
> 3 and Node.js, f_4 is 73.
> The result is shown as bellow:
> !image-2024-06-02-20-15-55-606.png!
> go-py3_json_buffered-ip_client.log
> !image-2024-06-02-20-16-08-144.png!
> go-go_json_buffered-ip_client.log
> The attachments provided are essential for reproducing the issue. By
> following the commands outlined in the accompanying readme.md, you will be
> able to replicate the problem accurately.
>
> *This is our first submission. If you have any preferred methods, please feel
> free to let us know. Thank you.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
