Age | Commit message (Collapse) | Author | Files | Lines |
|
Changed to use simple indexing instead of while (count--) in buf_read()/buf_write(),
because the count overflowed from 0 to max on the last iteration. While the unsigned
integer overflow is defined and behaviour was correct, making this simple change
allowed enabling the sanitizer which might catch true errors elsewhere in the code.
|
|
Mainly to clean up the code. Also fixed handling of
PB_LTYPE_FIXED_LENGTH_BYTES for proto3 files.
|
|
If the type is string, do not try to deference it as int16, int32 or int64.
This may lead to unalign memory access, which may cause trap on some architectures (ARM)
|
|
|
|
|
|
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).
|
|
|
|
This supports platforms where uint8_t does not exist.
If you are using a custom pb_syshdr.h, this may require adding
definitions for uint_least8_t etc.
|
|
This was never very clean code, but it was fast. Hopefully
compilers are smart enough to optimize it away, or the speed
difference is not very large. This should be checked.
However working code is always more important than fast code,
and the previous way couldn't really work for platforms that
do not have byte-sized memory access. Related to PR #191.
|
|
Basic test included, should probably add an oneof to the AllTypes test also.
Update issue 131
Status: Started
|
|
This allows overriding the integer field types to e.g. uint8_t for
saving RAM.
Update issue 139
Status: FixedInGit
|
|
|
|
This avoids possible namespace conflicts with other macros.
|
|
Update issue 82
Status: FixedInGit
|
|
Update issue 128
Status: FixedInGit
|
|
There is minimal size penalty from this, and it is probably much more
intuitive to use than PB_OSTREAM_SIZING itself.
This has been suggested before also, but I ended up refusing it back
them. Reconsidering it now, I see that an intuitive API is much better
than any amount of documentation explaining a non-intuitive API.
Update issue 16
Status: FixedInGit
|
|
Update issue 91
Status: FixedInGit
|
|
|
|
This makes the internal logic much simpler, and also keeps the datatypes
more similar between STATIC/POINTER cases. It will still be a bit cumbersome
to use because of variable length array member. Macros PB_BYTES_ARRAY_T(n) and
PB_BYTES_ARRAY_T_ALLOCSIZE(n) have been added to make life a bit easier.
This has the drawback that it is no longer as easy to use externally allocated
byte array as input for bytes field in pointer mode. However, this is still
easy to do using callbacks, so it shouldn't be a large issue.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Apparently int32 values that are negative must be cast into int64 first
before being encoded. Because uint32 still needs to be cast to uint64,
the cases for int32 and uint32 had to be separated.
Update issue 97
Status: FixedInGit
|
|
These have been deprecated since nanopb-0.1.6 (some since 0.1.3).
Equivalent functions with better interface are available in the API.
Update issue 91
Status: FixedInGit
|
|
For compliance with MISRA C rules (issue 91).
|
|
|
|
|
|
|
|
Update issue 90
Status: FixedInGit
|
|
|
|
Testing is still needed. Also only 'optional' extension fields
are supported now, 'repeated' fields are not yet supported.
|
|
|
|
Update issue 74
Status: FixedInGit
|
|
If the null terminator is not present, string will be limited to the
data size of the field.
If you are still using the pb_enc_string (deprecated since 0.1.3) from
callbacks, now would be an excellent time to stop. The pb_field_t for
the callback will not contain proper data_size. Use pb_encode_string()
instead.
Update issue 68
Status: FixedInGit
|
|
NOTE: This change breaks backwards-compatibility by default.
If you have old callback functions, you can define PB_OLD_CALLBACK_STYLE
to retain the old behaviour.
If you want to convert your old callbacks to new signature, you need
to do the following:
1) Change decode callback argument to void **arg
and encode callback argument to void * const *arg.
2) Change any reference to arg into *arg.
The rationale for making the new behaviour the default is that it
simplifies the common case of "allocate some memory in decode callback".
Update issue 69
Status: FixedInGit
|
|
This allows replacing the C99 standard include file names with
a single system-specific file. It should provide all the necessary
system functions (typedefs, memset, memcpy, strlen).
Update issue 62
Status: FixedInGit
|
|
Update issue 7
Status: FixedInGit
|
|
Also clean up the logic so that it is easier to implement more
allocation types in the future.
Update issue 53
Status: FixedInGit
|
|
This is a more logical name in parallel with PB_HTYPE_REQUIRED and PB_HTYPE_OPTIONAL.
Warning: This breaks backwards-compatibility of generated .pb.c files.
You will have to regenerate the files and recompile.
|
|
This allows slight optimizations if only memory buffer support
(as opposed to stream callbacks) is wanted. On ARM difference
is -12% execution time, -4% code size when enabled.
|
|
In the pb_istream_from_buffer and pb_ostream_from_buffer, memcpy was
used to transfer values to the buffer. For the common case of
count = 1-10 bytes, a simple loop is faster.
|
|
This should help avoid issue 33 in the future.
|
|
|
|
Update issue 27
Status: FixedInGit
|
|
Thanks to cea.max.simoes for bug report & fix.
Update issue 25
Status: FixedInGit
|
|
Main code is now compiled (for tests) with -pedantic -Wextra.
The test programs are not as strictly bound, but this should
improve the chances that atleast the core library compiles with
most compilers without warnings.
|
|
|
|
|