Copilot commented on code in PR #3859:
URL: https://github.com/apache/avro/pull/3859#discussion_r3567490678
##########
lang/c++/impl/Generic.cc:
##########
@@ -105,11 +267,38 @@ void GenericReader::read(GenericDatum &datum, Decoder &d,
bool isResolving) {
const NodePtr &nn = v.schema()->leafAt(0);
r.resize(0);
size_t start = 0;
+ // Only when not resolving: the datum schema then matches the wire
+ // schema, so minBytesPerElement is a true lower bound. Under
+ // resolution the wire (writer) type may be smaller than the datum
+ // (reader) type, which would over-estimate and reject valid data.
+ int64_t trueMin = minBytesPerElement(nn, 0);
+ // Under resolution the on-wire (writer) element can be zero bytes
+ // even when the reader element is not (e.g. reader-only fields
filled
+ // from defaults), so the bytes check is disabled and we cannot
tell
+ // whether an element is zero-byte on the wire. Apply the tighter
+ // zero-byte cap conservatively in that case, so the up-front
resize
+ // cannot be driven past it.
+ bool zeroByte = isResolving || trueMin == 0;
Review Comment:
In array decoding, `zeroByte` is forced true whenever `isResolving` is true
(`zeroByte = isResolving || trueMin == 0`). Because
`ensureZeroByteCollectionWithinLimit()` enforces a hard cumulative cap (default
10,000,000), this means *all* resolving array reads are limited to that cap
even when the on-wire element type is non-zero-byte. That is a behavior change
beyond “cap zero-byte elements”, and it also doesn’t match the nearby comment
that frames this as only preventing an up-front resize. Consider plumbing the
writer/on-wire element minimum through the resolving path (e.g., via
`ResolvingDecoder`) so the zero-byte cap is applied only when the writer
element can encode to 0 bytes, while still allowing legitimately large
resolving arrays of non-zero-byte elements.
--
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]
