Update issue 12
Still needs documentation.

pb_field_next() would access past the fields array.

Enable -fstack-protector-all to detect any stack smashing bugs. Also
use test_decode3 for maximal vulnerable surface.

Note: the bug only applies to empty message types. Empty messages
of non-empty message types are not affected.

Update issue 65
Status: FixedInGit

Update issue 64
Status: FixedInGit

This suits complex projects, where there are multiple interdependent .proto files
in various directories. Patch by Michael Haberler.

Patch courtesy of Michael Haberler.

This way the .pb.h will remain cleaner and easier to read.

Also clean up the logic so that it is easier to implement more
allocation types in the future.

Update issue 53
Status: FixedInGit

This is a more logical name in parallel with PB_HTYPE_REQUIRED and PB_HTYPE_OPTIONAL.

Warning: This breaks backwards-compatibility of generated .pb.c files.
You will have to regenerate the files and recompile.

This has the following advantages:
1) Easier to modify pb_field_t encoding
2) Simpler generator logic
3) Tidier looking, easier to read .pb.c files

Update issue 58
Status: FixedInGit

This is a bit bloated gitignore file. Having binaries
in a separate build directory would be cleaner, but I don't
bother to make that change now.

See issue #57.

Error messages were not propagated correctly with PB_HTYPE_ARRAY.
Error status (boolean return value) was correct.

Update issue 56
Status: FixedInGit

Update issue 54
Status: FixedInGit

Update issue 50
Status: FixedInGit

Results for ARM: -4% execution time, +1% code size

Results for ARM: -6% execution time, -1% code size

This allows slight optimizations if only memory buffer support
(as opposed to stream callbacks) is wanted. On ARM difference
is -12% execution time, -4% code size when enabled.

This avoids doing 64-bit arithmetic for 32-bit varint decodings.
It does increase the code size somewhat.

Results for ARM Cortex-M3: -10% execution time, +1% code size, -2% ram usage.

In the pb_istream_from_buffer and pb_ostream_from_buffer, memcpy was
used to transfer values to the buffer. For the common case of
count = 1-10 bytes, a simple loop is faster.

This fixes problems when interoperating with Java.

Fix suggested by trepidacious:
https://groups.google.com/forum/#!topic/nanopb/hZgrj6h9OnY