From https://developers.google.com/protocol-buffers/docs/proto3#updating:
int32, uint32, int64, uint64, and bool are all compatible – this means
you can change a field from one of these types to another without
breaking forwards- or backwards-compatibility. If a number is parsed
from the wire which doesn't fit in the corresponding type, you will
get the same effect as if you had cast the number to that type in C++
(e.g. if a 64-bit number is read as an int32, it will be truncated to
32 bits).
Until this fix, protobuf-c did not conform to the rule above when it
came to deserializing non-boolean packed repeated data into a
protobuf_c_boolean array. Fully scan the varint and use parse_boolean to
truncate the resulting value.
Fixes#440
Allows for generic oneof offset lookups based on the name of the oneof,
instead of having to know the field name. All oneof fields should have
the same offset, since they are members of a union.
Fixes#204
Allows treating proto strings as ProtobufCBinaryData to work around
limitations such as NULL characters in strings, which are allowed in
protobuf, but not allowed in 'char *' types.
Fixes#203
Add options controller helper function generation. Preserve existing
behavior of not generating pack/unpack functions for sub-messages if
option is not explicitly set.
Fixes#240Fixes#442
Allows suppression of .pb-c.{c,h} file generation on a .proto file
basis.
protobuf-c.proto: Use the new option in itself, because the options are
never used by protobuf-c runtime, only by the protoc-gen-c compiler.
t/test-full.proto: import protobuf-c.proto to test that
protobuf-c.pb-c.h dependency does not get included in test-full.pb-c.h.
The scan_length_prefixed_data() function returns the number of bytes
taken up by a varint length delimiter, plus the actual value of that
delimiter. Since it returns a uint32_t, a delimiter of 2^32 - 1 (or
close to that) could cause the return value to overflow and result in an
incorrect value.
At first I tried to fix it by making scan_length_prefixed_data() use a
size_t for its result, but I realized this would have no effect on
32-bit systems. To fix the problem for 32-bit, I changed the function to
return early if the length is 2 GiB or more (protobuf messages are not
allowed to be that large). I kept the size_t change anyway, since the
result will ultimately be stored in a size_t (ScannedMember.len) and we
might as well stay consistent with that.
Signed-off-by: Adam Cozzette <acozzette@google.com>
google::protobuf::Message::Reflection has been removed in newer versions
of protobuf. The replacement is google::protobuf::Reflection.
protobuf in commit 779f61c6a3ce02a119e28e802f229e61b69b9046 ("Integrate
recent changes from google3.", from August 2008) changed the following
in message.h:
@@ -336,7 +337,8 @@ class LIBPROTOBUF_EXPORT Message {
// Introspection ---------------------------------------------------
- class Reflection; // Defined below.
+ // Typedef for backwards-compatibility.
+ typedef google::protobuf::Reflection Reflection;
The "typedef for backwards-compatibility" apparently lasted ten years
until protobuf commit 6bbe197e9c1b6fc38cbdc45e3bf83fa7ced792a3
("Down-integrate from google3.", from August 2018) which finally removed
the typedef:
@@ -327,8 +344,6 @@ class LIBPROTOBUF_EXPORT Message : public MessageLite {
// Introspection ---------------------------------------------------
- // Typedef for backwards-compatibility.
- typedef google::protobuf::Reflection Reflection;
This commit updates the only use of this typedef (in the test suite) to
directly refer to the replacement, google::protobuf::Reflection. This
fixes the build failure in the test suite.
The spec talks about "empty string" and other languages like C#
return a zero length string and not null.
This is useful because when moving from proto2's "required string"
to a proto3's plain string we will be guaranteed that we
never get a null pointer.
The tradeoff is adding a special case to the library but avoiding
a lot of null checks in the calling code.
The current code is already special casing "" in pack_string.
This commit fixes a problem identified in #251. When generating the
PROTOBUF_C__FORCE_ENUM_TO_BE_INT_SIZE directive at the end of the enum
values generated for a oneof, we inadvertently only included the
protobuf class name in the call to the directive. This breaks if there
is more than one oneof per protobuf class, which causes duplicate enum
names to be generated.
This issue is fixed by also appending the oneof's name to the protobuf
class name when generating the PROTOBUF_C__FORCE_ENUM_TO_BE_INT_SIZE
directive, which should cause unique enum names to be generated.
This changes the enum name that is generated, but these names are
implementation details since they are sentinel values that only exist to
force the compiler to size the enum type correctly.
(The test case for #220 is updated since that test relies on the
oneof implementation details in the code generator.)
This makes __free_unpacked() consistent with free(), and simplifies
callers by allowing them to indiscriminately free message objects
without regard to whether they have been allocated or not.
Fix a few casts where ints were cast to uints unnecessarily
Fixes#199. Previously, enums were treated as uint32's, but they need to
be treated as int32's instead.
t: Add a few test cases with negative enum values
warning: assigning to 'uint8_t *' (aka 'unsigned char *')
from 'char *' converts between pointers to integer types
with different sign [-Wpointer-sign]
protobuf 2.5.0 started warning that we would need to enable the
'allow_alias' option on this enum due to the duplicate enum values, and
protobuf 2.6.0 turned this into an error. Turn this option on, now that
protobuf 2.5.0 is more common (e.g., it's now in Ubuntu 14.04 LTS). This
will break with older protobuf versions, so we now require >= 2.5.0.
We should now see diagnostics like these disappear from the build log:
[libprotobuf ERROR google/protobuf/descriptor.cc:4153] "foo.VALUE_B" uses the same enum value as "foo.VALUE_A". If this is intended, set 'option allow_alias = true;' to the enum definition.
Based on a patch from Ilya Lipnitskiy.
added check that repeated fields vectors are not NULL
fixed repeated field quantity type: it's "size_t", not "unsigned"
cleaner code, no cast porn
all covered with tests
i'm confused as to why these fields exist, since the typical
implementation of a "temporary alloc" would be something like alloca(),
and alloca() is usually just inlined code that adjusts the stack
pointer, which is not a function whose address could be taken.
this breaks the API/ABI and will require a note in the ChangeLog.
possibly we could revisit the idea of "temporary allocations" by using
C99 variable length arrays. this would have the advantage of being
standardized, unlike alloca().
of the same field on the wire (Fixes#91)
t/generated-code2/test-generated-code2.c: add a test case for merging
messages
t/test-full.proto: expand message definitions to test for merging nested
messages
