Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also modified a few tests to be more compatible with coverage information,
so that they use the same pb_encode/decode.c instead of making a copy.
|
|
|
|
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
|
|
Update issue 112
Status: FixedInGit
|
|
Update issue 91
Status: FixedInGit
|
|
|
|
Update issue 111
Status: FixedInGit
|
|
|