Allocation decision is now made before the field data type is decided.
This way the data type decisions can more cleanly account for the allocation
type, i.e. FT_DEFAULT logic etc.
Added pb_bytes_ptr_t for pointer-allocated bytes-fields. There is no point
generating separate structs for these, as they would all be of the same type.
Some compilers where unable to detect that the ternary operator
can be evaluated at the compile time. This commit does the evaluation
on the Python side, which should fix the problem.
The new .pb.c files are generated using PB_FIELD2() macro. The old
PB_FIELD() macro remains, so that previously generated files keep
working.
Previously the generator would stop with NotImplementedException as
soon as a required or repeated extension field is found. New behaviour
is to just ignore the unsupported field and note that in a comment
in the generated file.
Furthermore, allow skipping of extension fields using the generator
option (nanopb).type = FT_IGNORE.
Update issue 83
Status: FixedInGit
Also add note about the 'packed' message option being incompatible
with CPUs that do not support unaligned access.
Update issue 12
Status: FixedInGit
Update issue 77
Status: FixedInGit
The arg field can be used to store the field presence from inside
the callback. Furthermore, having the has_ field for encoding callbacks
would be more annoying than useful.
Update issue 70
Status: FixedInGit
This has the following advantages:
1) Easier to modify pb_field_t encoding
2) Simpler generator logic
3) Tidier looking, easier to read .pb.c files
Update issue 58
Status: FixedInGit
This allows ignoring fields that are unnecessary or too large for an
embedded system using nanopb, while allowing them to remain in the .proto
for other platforms.
Update issue 51
Status: FixedInGit
The __COUNTER__ macro (used for generating unique names) is at least supported
by gcc, clang and Visual Studio. With this change test_compiles.c is
compilable, since no more typedefs are redefined.
Compilers/Preprocessors not supporting __COUNTER__ error's are still possible
which are hopfully handled by the usage of __LINE__ in most sittuations.
Added unit test for the problem.
