[
https://issues.apache.org/jira/browse/THRIFT-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112868#comment-18112868
]
Sylwester Lachiewicz commented on THRIFT-5149:
----------------------------------------------
Retracting my previous comment - it was wrong. {{container_limit_}} bounds the
element *count*, not the memory the count implies, and the issue text already
stipulates that limit exists. The request here is orthogonal and still open.
Concretely: generated C++ preallocates before reading any element
([t_cpp_generator.cc:4464|https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/generate/t_cpp_generator.cc#L4464]
emits {{resize(_size)}} after {{readListBegin}}), so a wire-supplied count of
N allocates N x sizeof(element) regardless of how few bytes the input actually
carries. An element-count limit cannot separate {{list<byte>}} from a list of a
512-byte struct.
One complication for anyone implementing this: C++ has no remaining-bytes
facility on {{TTransport}}/{{TProtocol}} (the Go binding uses one for a
comparable check), so a byte budget would need either a protocol-level budget
decremented per element or a new transport-side hook.
_This comment was created with AI assistance._
> Limit container byte size
> -------------------------
>
> Key: THRIFT-5149
> URL: https://issues.apache.org/jira/browse/THRIFT-5149
> Project: Thrift
> Issue Type: Wish
> Components: C++ - Library
> Reporter: Antoine Pitrou
> Priority: Major
>
> The C++ library currently takes a container size limit which can avoid
> instantiating too large containers, limiting the possibility of memory bombs.
> However, some container elements may be very large and preallocating such a
> large container may blow up memory even if the number of elements "looks"
> reasonable. This allows for very small files to blow up memory (and therefore
> to be potential denial-of-service material).
> It would be nice to have an additional parameter to limit in-memory container
> byte size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
