Age | Commit message (Collapse) | Author | Files | Lines |
|
This check will help to detect bugs earlier, and is quite lightweight
compared to malloc() anyway.
|
|
If a required or optional field appeared twice in the message data,
pb_decode will overwrite the old data with new one. That is fine, but
with submessage fields, it didn't release the allocated subfields before
overwriting.
This bug can manifest if all of the following conditions are true:
1. There is a message with a "optional" or "required" submessage field
that has type:FT_POINTER.
2. The submessage contains atleast one field with type:FT_POINTER.
3. The message data to be decoded has the submessage field twice in it.
|
|
There was a double-free bug in pb_release() because it didn't set size fields
to zero after deallocation. Most commonly this happens if pb_decode() fails,
internally calls pb_release() and then application code also calls pb_release().
|
|
This avoids possible namespace conflicts with other macros.
|
|
Update issue 82
Status: FixedInGit
|
|
Update issue 128
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
|
|
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
|
|
Update issue 112
Status: FixedInGit
|
|
Update issue 91
Status: FixedInGit
|
|
|
|
|
|
|
|
This makes the internal logic much simpler, and also keeps the datatypes
more similar between STATIC/POINTER cases. It will still be a bit cumbersome
to use because of variable length array member. Macros PB_BYTES_ARRAY_T(n) and
PB_BYTES_ARRAY_T_ALLOCSIZE(n) have been added to make life a bit easier.
This has the drawback that it is no longer as easy to use externally allocated
byte array as input for bytes field in pointer mode. However, this is still
easy to do using callbacks, so it shouldn't be a large issue.
|
|
|
|
|
|
|
|
|
|
Apparently int32 values that are negative must be cast into int64 first
before being encoded. Because uint32 still needs to be cast to uint64,
the cases for int32 and uint32 had to be separated.
Update issue 97
Status: FixedInGit
|
|
For PB_BUFFER_ONLY configuration, this gives 20% speedup without
increasing code size.
|
|
These have been deprecated since nanopb-0.1.6 (some since 0.1.3).
Equivalent functions with better interface are available in the API.
Update issue 91
Status: FixedInGit
|
|
For compliance with MISRA C rules (issue 91).
|
|
|
|
|
|
Testing is still needed. Also only 'optional' extension fields
are supported now, 'repeated' fields are not yet supported.
|
|
If you have a message that defined as empty, but attempt to decode a
message that has one or more unknown fields then pb_decode fails. The
method used to count the number of required fields counts 1 required
field because the default type of PB_LAST_FIELD is PB_HTYPE_REQUIRED.
|
|
Update issue 74
Status: FixedInGit
|
|
Fix suggested by Henrik Carlgren. Added also unit test for the bug.
Update issue 73
Status: FixedInGit
|
|
Patch from dch.
|
|
NOTE: This change breaks backwards-compatibility by default.
If you have old callback functions, you can define PB_OLD_CALLBACK_STYLE
to retain the old behaviour.
If you want to convert your old callbacks to new signature, you need
to do the following:
1) Change decode callback argument to void **arg
and encode callback argument to void * const *arg.
2) Change any reference to arg into *arg.
The rationale for making the new behaviour the default is that it
simplifies the common case of "allocate some memory in decode callback".
Update issue 69
Status: FixedInGit
|
|
This allows replacing the C99 standard include file names with
a single system-specific file. It should provide all the necessary
system functions (typedefs, memset, memcpy, strlen).
Update issue 62
Status: FixedInGit
|
|
This avoids a name clash when compiling as Linux kernel module.
Update issue 60
Status: FixedInGit
|
|
pb_field_next() would access past the fields array.
|
|
Note: the bug only applies to empty message types. Empty messages
of non-empty message types are not affected.
Update issue 65
Status: FixedInGit
|
|
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.
|
|
Error messages were not propagated correctly with PB_HTYPE_ARRAY.
Error status (boolean return value) was correct.
Update issue 56
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.
|
|
|
|
|
|
Update issue 52
Status: FixedInGit
|
|
Because PB_RETURN_ERROR checks if the 'errmsg' member is NULL before
assigning to it, error messages would get lost.
|