Update issue 126
Status: Started

Update issue 130
Status: Started

The version in PB_PROTO_HEADER_VERSION can be bumped whenever there
is a breaking change to the generated files, and it will then alert
to the difference.

Update issue 129
Status: FixedInGit

Update issue 106
Status: FixedInGit

This avoids possible namespace conflicts with other macros.

Update issue 82
Status: FixedInGit

Update issue 128
Status: FixedInGit

Usage like:
MyMessage foo = MyMessage_init_default;

MyMessage_init_default will initialize to default values defined in .proto.

MyMessage_init_zero will initialize to null/zero values. Same results as {}
or {0}, but will avoid compiler warnings by initializing everything explicitly.

Update issue 79
Status: FixedInGit

Update issue 121
Status: FixedInGit

Update issue 123
Status: FixedInGit

Now -e option in generator is more versatile. Especially it avoids
double-dot problem with some build systems.

Given foobar.proto, we now get:
-e .pb  =>  foobar.pb.c (default)
-e _pb  =>  foobar_pb.c
-e ''   =>  foobar.c

Note that if you have used -e option previously, you will have to prepend
. to the argument to get the same filenames as before.

Update issue 122
Status: FixedInGit

Update issue 124
Status: FixedInGit

The options for an extension field were being looked up under wrong name
(MessageName instead of MessageName.fieldname).

Fixed the problem and added regression test. Created a new subfolder for
regression test cases.

Update issue 125
Status: FixedInGit

Back in design phase the code used realloc() for freeing the memory
also. However, this is not entirely portable, and therefore the finished
implementation used free() separately.

There were some remnants of the size = 0 code in the allocate_field()
code, which made it somewhat confusing. This change makes it clearer
that size = 0 is not allowed (and not used by nanopb).

Update issue 120
Status: FixedInGit

Patch from Jon Read.

Update issue 119
Status: FixedInGit

The multiplication in allocate_field could potentially overflow,
leading to allocating too little memory. This could subsequently
allow an attacker to cause a write past the buffer, overwriting
other memory contents.

The attack is possible if untrusted message data is decoded using
nanopb, and the message type includes a pointer-type string or bytes
field, or a repeated numeric field. Submessage fields are not
affected.

This issue only affects systems that have been compiled with
PB_ENABLE_MALLOC enabled. Only version nanopb-0.2.7 is affected,
as prior versions do not include this functionality.

Update issue 117
Status: FixedInGit

Patch by rusnakp.

Update issue 115
Status: FixedInGit