Skip to content

Conversation

@zonque
Copy link

@zonque zonque commented Mar 30, 2018

Currently, the VCDiffStreamingDecoder class expects applications to call into ::StartDecoding() with a dictionary, and then maintains an internal buffer (decoded_target_) to accumulate pending output bytes. These are then written through ::AppendNewOutputText() and ::FlushDecodedTarget().

The problem with this implementation is that the allocation of this intermediate buffer may fail, which will then result in the application abort with a trap.

This patch adds an alternative interface that does not lead to internal allocation. StartDecoding() may now optionally be called with an output buffer and a maximum length, and DecodeChunk() may be called without an OutputString parameter. If operated this way, the decoder will directly write to the provided memory buffer, which can, for instance, be mmap()ed on a block device.

The old interface is kept around for full compatibility.

This should address #12.

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

Currently, the VCDiffStreamingDecoder class expects applications to call
into ::StartDecoding() with a dictionary, and then maintains an internal
buffer (decoded_target_) to accumulate pending output bytes. These are then
written through ::AppendNewOutputText() and ::FlushDecodedTarget().

The problem with this implementation is that the allocation of this
intermediate buffer may fail, which will then result in the application
abort with a trap.

This patch adds an alternative interface that does not lead to internal
allocation. StartDecoding() may now optionally be called with an output
buffer and a maximum length, and DecodeChunk() may be called without an
OutputString parameter. If operated this way, the decoder will directly
write to the provided memory buffer, which can, for instance, be mmap()ed
on a block device.

The old interface is kept around for full compatibility.
@zonque
Copy link
Author

zonque commented Apr 17, 2018

I signed it!

@googlebot
Copy link

CLAs look good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants