rik/nanopb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed issue 1 reported by Erik Rosen:

Browse Source 
The size of non-callback bytes-fields was miscalculated, which
caused all following fields in a message to contain garbage.

Previous commit contains a testcase for this.

This fix changes the generated message description. If your protocol uses
bytes-fields, you should regenerate *.pb.c.
This commit is contained in:
Petteri Aimonen
2012-01-12 19:08:05 +02:00
parent 0f6b615ae3
commit 113bd7ee87
4 changed files with 17 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/concepts.rst
View File

@@ -158,7 +158,10 @@ required bytes data = 1 [(nanopb).max_size = 40];
| Person_data_t data;
=============================================================================== =======================
The maximum lengths are checked in runtime. If string/bytes/array exceeds the allocated length, *pb_decode* will return false.
The maximum lengths are checked in runtime. If string/bytes/array exceeds the allocated length, *pb_decode* will return false.
Note: for the *bytes* datatype, the field length checking may not be exact.
The compiler may add some padding to the *pb_bytes_t* structure, and the nanopb runtime doesn't know how much of the structure size is padding. Therefore it uses the whole length of the structure for storing data, which is not very smart but shouldn't cause problems. In practise, this means that if you specify *(nanopb).max_size=5* on a *bytes* field, you may be able to store 6 bytes there. For the *string* field type, the length limit is exact.
Field callbacks
===============