mlot / nanopb

Automatically exported from code.google.com/p/nanopb
zlib License
0 stars 0 forks source link

Please provide a "pb_seek" interface #137

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Describe the requested feature:

A "pb_seek" interface that tells nanopb to update its internal state to match 
some other buffer write done outside of the nanopb framework.

In what situation would the feature be useful:

Some functions already write into memory; writing into a temporary buffer and 
then calling pb_write from that buffer into the stream is wasteful. The 
alternative of writing directly into the stream and than calling pb_write 
"in-place" also works, but is also wasteful (reading/writing the stream memory 
with no modification).

Example functions:

+ memset/memcpy/strcpy
+ printf and friends
+ cryptographic and other transformative functions that can read from one piece 
of memory and write to another piece of memory

In all above cases, it would be nice to have a "pb_seek" function that does the 
same as "pb_write" (for updating stream->state, stream->bytes_written, etc.) 
except for the memcpy part of it (since it was already done "out-of-band").

I've attached an example implementation. An actual integrated patch could 
perhaps be slightly more efficient by having buf_write call buf_seek, then 
copying the memory.

I think such a feature only makes sense for PB_BUFFER_ONLY since the meaning of 
"stream->state" is very specific to the buffer implementation and could mean 
something completely different for a custom callback.

Original issue reported on code.google.com by robt...@google.com on 12 Dec 2014 at 11:23

Attachments:

GoogleCodeExporter commented 9 years ago
I can see the purpose. However, as you say, it would really only work for 
memory buffer streams.

I wonder if instead the interface should be like

int maxbytes = stream->begin_buffer_write();
...
stream->end_buffer_write(bytes_written);

because that could work for further reducing the overhead of stream writes. It 
would allow e.g. writing the submessage length after the submessage contents, 
which is something that is quite inefficient in nanopb currently. And then even 
non-memory streams could provide a small memory buffer for speed.

Original comment by Petteri.Aimonen on 13 Dec 2014 at 7:57