Jens-G opened a new pull request, #3754: URL: https://github.com/apache/thrift/pull/3754
`TFramedTransport` has three constructors. The two that take an underlying transport initialise `maxFrameSize_` from the configuration; the one that takes only a `TConfiguration` leaves it out of its member-init list, so `getMaxFrameSize()` reads an uninitialised member and the frame-size limit it reports is whatever happened to be on the stack. The added test observed `0` and `21988` against a configured `4096` before the fix. Nothing in the tree uses that constructor, so this is only reachable from outside the library, and a transport built that way has no underlying transport to read from until one is set. It is still an uninitialised read of a member that decides a size limit, and the three constructors should agree. ### Test `TTransportFactoryConfigTest` gains one case pinning all three constructors against the configuration, so they cannot drift apart again. It states the contract rather than claiming to detect the defect reliably โ reading an indeterminate value is undefined, so a run that happened to find the right bytes there would pass. Verified in the `thrift:jammy` container: `TTransportFactoryConfigTest`, `UnitTests` and `TransportTest` all pass. Formatting checked with `clang-format` against `.clang-format` (the files carry pre-existing drift; the added lines are clean). No JIRA ticket โ this is a one-line fix under the "minor / quick fixes" heading in `AGENTS.md` ยง2. ๐ค Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_017kupyUgWdzLC2HapLuCgh9 -- 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]
