diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/concepts.rst | 5 | ||||
-rw-r--r-- | docs/migration.rst | 35 | ||||
-rw-r--r-- | docs/reference.rst | 4 | ||||
-rw-r--r-- | docs/security.rst | 1 |
4 files changed, 44 insertions, 1 deletions
diff --git a/docs/concepts.rst b/docs/concepts.rst index 1f9aec1..168e564 100644 --- a/docs/concepts.rst +++ b/docs/concepts.rst @@ -317,6 +317,11 @@ The user is expected to set the filed manually using the correct field tag:: Notice that neither ``which_payload`` field nor the unused fileds in ``payload`` will consume any space in the resulting encoded message. +When a C union is used to represent a ``oneof`` section, the union cannot have +callback fields or nested callback fields. Otherwise, the decoding process may +fail. If callbacks must be used inside a ``oneof`` section, the generator +option *no_unions* should be set to *true* for that section. + .. _`oneof`: https://developers.google.com/protocol-buffers/docs/reference/proto2-spec#oneof_and_oneof_field Extension fields diff --git a/docs/migration.rst b/docs/migration.rst index fdc1d8c..d358600 100644 --- a/docs/migration.rst +++ b/docs/migration.rst @@ -11,7 +11,40 @@ are included, in order to make it easier to find this document. .. contents :: -Nanopb-0.3.9.1, 0.4.0 (2018-xx-xx) +Nanopb-0.3.9.4, 0.4.0 (2019-xx-xx) +================================== + +Fix generation of min/max defines for enum types +------------------------------------------------ + +**Rationale:** Nanopb generator makes #defines for enum minimum and maximum +value. Previously these defines incorrectly had the first and last enum value, +instead of the actual minimum and maximum. (issue #405) + +**Changes:** Minimum define now always has the smallest value, and maximum +define always has the largest value. + +**Required actions:** If these defines are used and enum values in .proto file +are not defined in ascending order, user code behaviour may change. Check that +user code doesn't expect the old, incorrect first/last behaviour. + +Fix undefined behavior related to bool fields +--------------------------------------------- + +**Rationale:** In C99, `bool` variables are not allowed to have other values +than `true` and `false`. Compilers use this fact in optimization, and constructs +like `int foo = msg.has_field ? 100 : 0` will give unexpected results otherwise. +Previously nanopb didn't enforce that decoded bool fields had valid values. + +**Changes:** Bool fields are now handled separately as `PB_LTYPE_BOOL`. The +`LTYPE` descriptor numbers for other field types were renumbered. + +**Required actions:** Source code files must be recompiled, but regenerating +`.pb.h`/`.pb.c` files from `.proto` is not required. If user code directly uses +the nanopb internal field representation (search for `PB_LTYPE_VARINT` in source), +it may need updating. + +Nanopb-0.3.9.1, 0.4.0 (2018-04-14) ================================== Fix handling of string and bytes default values diff --git a/docs/reference.rst b/docs/reference.rst index 40a69ad..89d1f0f 100644 --- a/docs/reference.rst +++ b/docs/reference.rst @@ -55,6 +55,10 @@ PB_SYSTEM_HEADER Replace the standard header files with a single for example *#define PB_SYSTEM_HEADER "foo.h"*. PB_WITHOUT_64BIT Disable 64-bit support, for old compilers or for a slight speedup on 8-bit platforms. +PB_ENCODE_ARRAYS_UNPACKED Don't encode scalar arrays as packed. + This is only to be used when the decoder on the + receiving side cannot process packed scalar + arrays. Such example is older protobuf.js. ============================ ================================================ The PB_MAX_REQUIRED_FIELDS, PB_FIELD_16BIT and PB_FIELD_32BIT settings allow diff --git a/docs/security.rst b/docs/security.rst index d854612..6f7152e 100644 --- a/docs/security.rst +++ b/docs/security.rst @@ -58,6 +58,7 @@ untrusted data has been maliciously crafted: - The *count* fields of arrays will not exceed the array size. - The *size* field of bytes will not exceed the allocated size. - All string fields will have null terminator. + - bool fields will have valid true/false values (since nanopb-0.3.9.4) 5. After pb_encode() returns successfully, the resulting message is a valid protocol buffers message. (Except if user-defined callbacks write incorrect |