kpumuk opened a new pull request, #3745:
URL: https://github.com/apache/thrift/pull/3745
<!-- Explain the changes in the pull request below: -->
Ruby's pure `CompactProtocol` can return values outside the declared `i16`
and `i64` widths for oversized on-wire varints. The native extension narrows
the same bits, so identical Compact payloads can produce different application
values depending on whether `thrift_native` loaded.
This change explicitly narrows pure-Ruby `i16` and `i64` reads to their
declared signed widths. It aligns the pure implementation with the established
native behavior while leaving valid encodings and the existing unsigned-varint
overflow validation unchanged.
## Benchmarks
The existing `rb-cmp-read-small` protocol benchmark scenario was run through
a temporary repetition wrapper in deliberately pure-Ruby mode. Each trial
deserialized 20,000 `OneOfEach` structures; both revisions used Ruby 4.0.6 in
the same worktree container, with 3 warmup runs and 11 measured trials.
Command: `docker exec --workdir /thrift/src thrift-3422 ruby
/thrift/src/.rb041-benchmark.rb`
| Revision | Median | Throughput |
| --- | ---: | ---: |
| `upstream/master` (`04c87e89a`) | 0.347059 s | 57,627 structures/s |
| Proposed change | 0.352414 s | 56,751 structures/s |
The proposed median was 1.5% slower and throughput was 1.5% lower. This
in-memory pure-Ruby workload emphasizes Compact decoding overhead and excludes
transport, application, and native-extension work; the observed difference is
small enough to overlap normal local benchmark variation.
<!-- We recommend you review the checklist/tips before submitting a pull
request. -->
- [x] Did you create an [Apache
Jira](https://issues.apache.org/jira/projects/THRIFT/issues/) ticket?
[THRIFT-6157](https://issues.apache.org/jira/browse/THRIFT-6157)
- [x] If a ticket exists: Does your pull request title follow the pattern
"THRIFT-NNNN: describe my issue"?
- [x] Did you squash your changes to a single commit? (not required, but
preferred)
- [x] Did you do your best to avoid breaking changes? If one was needed,
did you label the Jira ticket with "Breaking-Change"?
- [ ] If your change does not involve any code, include `[skip ci]` anywhere
in the commit message to free up build resources.
<!--
The Contributing Guide at:
https://github.com/apache/thrift/blob/master/CONTRIBUTING.md
has more details and tips for committing properly.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
