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
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
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
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).
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
There is minimal size penalty from this, and it is probably much more
intuitive to use than PB_OSTREAM_SIZING itself.
This has been suggested before also, but I ended up refusing it back
them. Reconsidering it now, I see that an intuitive API is much better
than any amount of documentation explaining a non-intuitive API.
Update issue 16
Status: FixedInGit
