Age | Commit message (Collapse) | Author |
|
74741d77d4 am: 05a8588518 am: 1c7089bdbd
Change-Id: I5f0ce9bd8e140a51aa160a56a576c0fccf682aa9
|
|
74741d77d4 am: 05a8588518
Change-Id: I8bb327b433673240716c9a53b7c8f7bfb15711c2
|
|
74741d77d4
Change-Id: Ic1739f89569dce800c3883da4dfd469947b7e95e
|
|
Change-Id: Ib4b647b60a73f9d85f9c327ef40b27153136614a
|
|
Bug: 68860345
Bug: 69058154
Bug: 151953481
Test: no code changes
Change-Id: I1d97d7392e071c520ccef35b986895b959c8cf28
|
|
Regression test + fix for proto3 submessage improperly considered empty
|
|
|
|
This will only occur with unlimited length streams, so it's kind-of
low impact. Such streams allow denial of service anyway.
|
|
|
|
|
|
|
|
Repeated callback fields were being treated as "always present",
even if the callback pointer wasn't set.
|
|
|
|
|
|
|
|
This reverts commit 597c747e5365fd5599d8aa0e6bb8c9bb882a95ee.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously nanopb didn't enforce that decoded bool fields
had valid true/false values. This could lead to undefined
behavior in user code.
This has potential security implications when
1) message contains bool field (has_ fields are safe)
and
2) user code uses ternary operator dependent on the field value,
such as: int value = msg.my_bool ? 1234 : 0
and
3) the value returned from ternary operator affects a memory access,
such as: data_array[value] = 9999
|
|
|
|
|
|
This could happen with zero-length submessages and strings.
While technically valid, it is an useless call and a rare
corner case that can easily lead to bugs in the callback
implementation.
|
|
Previously the example code would falsely detect EOF condition if
called with count = 0.
|
|
|
|
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.
|
|
|
|
Unsorted enums in message specifications do not result in correct
min/max values per the protobuf spec for cpp code:
https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#enum
The google cpp compiler uses the min/max _value_ instead of the position
of the enum entry in the message spec, so this patch updates nanopb to
do the same.
Example input:
```protobuf
syntax = "proto3";
enum Language {
UNKNOWN = 0;
ENGLISH_EN_GB = 12;
ENGLISH_EN_US = 1;
FRENCH_FR_FR = 2;
ITALIAN_IT_IT = 3;
GERMAN_DE_DE = 4;
SPANISH_ES_AR = 13;
SPANISH_ES_ES = 5;
SPANISH_ES_MX = 14;
SWEDISH_SV_SE = 6;
DUTCH_NL_NL = 7;
KOREAN_KO_KR = 8;
JAPANESE_JA_JP = 9;
CHINESE_SIMPLIFIED_ZH_CN = 10;
CHINESE_TRADITIONAL_ZH_TW = 11;
}
```
This would previously result in:
```c
#define _Language_MIN Language_UNKNOWN
#define _Language_MAX Language_CHINESE_TRADITIONAL_ZH_TW
#define _Language_ARRAYSIZE ((Language)(Language_CHINESE_TRADITIONAL_ZH_TW+1))
```
After this patch,
```c
#define _Language_MIN Language_UNKNOWN
#define _Language_MAX Language_SPANISH_ES_MX
#define _Language_ARRAYSIZE ((Language)(Language_SPANISH_ES_MX+1))
```
Add a test `enum_minmax` to cover this case.
|
|
am: 07c127e075
Change-Id: I248ee8847450b3145c0ac9b06237d89f61a90a2d
|
|
am: b97cbd30e1
Change-Id: I0404d46f7f784ecd131080a4c1e755ccadc285e7
|
|
am: d8d508fb38
Change-Id: Ic059ea63104522e35704990577930b11dc16e02f
|
|
Test: compile
Change-Id: I9d5cb0b1d63cd38717f4a8e15785058da84262a4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
am: 1d0ca59852
Change-Id: I412488a20b4fcfa05f58528c2e38fff5a7e3a0c0
|
|
am: aaae7fff6e
Change-Id: I7e9b49665176548ce0c7d5e5c9f3c62ec37d5650
|
|
am: 3f5b6d4262
Change-Id: I2f79eba12ecf6e8d7ab7ed2d102bbe745c0b6c0c
|
|
Add 32BIT and 16BIT compile time flag for nanopb library to support
16BIT or 32BIT size, default is 8BIT. User need to use the corresponding
library when define the PB_FIELD_* flag during compilation.
Test: None
Bug: 122292884
Change-Id: I1b3c572e54297d020776e7721d37b65526f1a0ff
|
|
am: e80a74a431
Change-Id: I120cf2f5451910c68e9ebfad9d86358c02b32098
|
|
am: eeedc9b64b
Change-Id: I3355d9aa570683a1488f528752342ce4527c6190
|
|
am: 4090366181
Change-Id: Ic5a149eb6e898140647c92aa446f5614cfbcb7d0
|
|
Bug: 123068679
Change-Id: I7b75d9d7c8a8980bcceafc44580fb70ce4d31938
|