Age | Commit message (Collapse) | Author | Files | Lines |
|
Previously the field iterator logic didn't know whether two
oneof fields were part of the same union, or separate. This
caused wrong pointers to be calculated if multiple oneofs were
inside a single message.
This commit fixes this by using dataoffset of PB_SIZE_MAX to
indicate union fields after the first field.
Theoretically PB_SIZE_MAX is also a valid value for data offset,
which could cause errors. Adding a compile-time assert for this
is somewhat difficult. However I consider it extremely unlikely
that there is any platform that could trigger this situation, as
it would require 255 bytes of extra data/padding between two protobuf
oneof fields. On 64-bit architectures the worst case is 16 bytes,
and even esoteric platforms only align to 64 bytes or so. Manual
modification of the generated .pb.h file could trigger this, but
even then it would require pretty bad luck to happen.
|
|
|
|
|
|
Google-Bug-Id: 28000875
Signed-off-by: William A. Kennington III <wak@google.com>
Change-Id: I1bffd39168abe04593588291b0ebbe5199a00138
|
|
|
|
|
|
|
|
Need to generate compile time check if the bytes field + size field
might exceed 255 bytes. Also eliminated spurious checks generated
for some callback fields.
|
|
|
|
This commit adds a new FT_INLINE allocation type that forces bytes
fields to be inlined into the struct. E.g., pb_byte_t my_bytes[32].
This requires max_size for the bytes field. The FT_INLINE type is
represented as a new LTYPE: FT_LTYPE_FIXED_LENGTH_BYTES.
This commit also updates the documentation with FT_INLINE and
FT_LTYPE_FIXED_LENGTH_BYTES.
Added an AUTHORS file in apparent order of appearance in the git log
history from $(git log --all).
|
|
Fix suggested by Ulenspiegel.
Also added testcase for the same.
|
|
|
|
|
|
The FieldMaxSize class was reusing the same list instance,
causing problems when multiple files were specified on the
protoc command line.
|
|
|
|
Generate MIN/MAX/ARRAYSIZE for enums
|
|
This generates #defines mirroring the following values from the generated C++ code of GPB
* const Foo Foo_MIN: the smallest valid value of the enum (VALUE_A in the example).
* const Foo Foo_MAX: the largest valid value of the enum (VALUE_C in the example).
* const Foo Foo_ARRAYSIZE: always defined as Foo_MAX + 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add testcase for the same.
|
|
Fixes compilation error with anonymous unions when
it is not the last field in message. Also fixes
extraneous newlines in header file. Cleanup the
pb.h extraneous use of ##.
|
|
|
|
* Remove trailing whitespace
* No functional changes
|
|
This bug was triggered when:
1. A .proto file included another .proto from a different directory.
2. The another .proto has an associated .options file.
Added regression test for the same.
|
|
|
|
Add proper Python3 support to the generator
|
|
|
|
|
|
* Search $PATH for the python binary so that this works better with
things like virtualenv as used on Travis CI
|
|
* Work around this by checking the appropriate class for the given
* environment.
|
|
* This is a shot in the dark.
|
|
* Not sure how to handle this case in python2, seems to work
* Python 3 doesn't need this since all strings are utf-8
|
|
* Python3 ignores cmp() and __cmp__() and only needs __lt__() for
sorting. Delete and update as appropriate.
* Ref: https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons
|
|
Create a FieldMaxSize class that:
* Accumlates all C assertions
* Handles the checking of the longest simple field
* Also python3 doesn't support max(None)
|
|
* This works with python2 and python3
|
|
* Invoked with `2to3 -w nanopb_generator.py`
* No other changes.
|
|
Python2 is being phased out of the default python interpreter. Arch
Linux has moved some time ago and upcoming Debian realeases will follow.
My distro, Arch, doesn't have a python2-protobuf version, but does have
a python3 version. With a python 2 & 3 compatible generator the exact
interpreter can be ignored and can use the system default as most users
expect.
Update issue #155
|
|
|
|
This will allow message sizes and enum options to be available
across the include files.
Currently searching for .options files for included files may
not work for all path combinations, this is related to issue #116.
Should probably make a pull request to protoc about that.
|
|
In preparation for multi-file support in generator.
No functional changes yet.
|
|
Previously unsigned enums would throw errors on decoding if the value
went outside the signed range (issue #164).
Currently only helps for enums defined within the same file, but solving
issue #165 will make it work for multiple files also.
|
|
This can be generally useful for saving RAM, but also makes
it easier to test for issue #164.
|
|
|
|
Update issue 155
Status: FixedInGit
|
|
|
|
|