Copilot commented on code in PR #3859:
URL: https://github.com/apache/avro/pull/3859#discussion_r3567609431


##########
lang/c++/impl/Stream.cc:
##########
@@ -119,6 +130,10 @@ class MemoryInputStream2 : public InputStream {
     size_t byteCount() const final {
         return curLen_;
     }
+
+    int64_t remainingBytes() const final {
+        return static_cast<int64_t>(size_ - curLen_);
+    }

Review Comment:
   MemoryInputStream2::remainingBytes() computes (size_ - curLen_) in size_t 
before casting to int64_t. If an invariant is ever violated (e.g., a too-large 
backup()), that subtraction underflows and returns a huge positive remaining 
count, weakening the allocation/available-bytes guard. Compute the subtraction 
in int64_t to avoid unsigned underflow.



##########
lang/c++/include/avro/Decoder.hh:
##########
@@ -169,6 +169,14 @@ public:
     /// by the avro decoder. Similar set of problems occur if the Decoder
     /// consumes more than what it should.
     virtual void drain() = 0;
+
+    /// Returns the number of bytes that remain to be read from the underlying
+    /// stream, or a negative value when that count is not known (for example a
+    /// streaming source, or a decoder not backed by a byte stream). The 
default
+    /// is "unknown"; byte-stream decoders override it so a length prefix or a
+    /// collection block count that exceeds the data actually available can be
+    /// rejected before allocating for it.
+    virtual int64_t bytesRemaining() const { return -1; }

Review Comment:
   Adding new virtual methods to public interfaces (InputStream::remainingBytes 
and Decoder::bytesRemaining) changes vtable layout and is an ABI-breaking 
change for downstream code that subclasses these types across shared-library 
boundaries. If the C++ SDK aims to preserve binary compatibility across 
patch/minor releases, this needs a strategy (e.g., a new derived interface, 
pimpl, or a major-version/SONAME bump) and release-note callout.



-- 
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]

Reply via email to