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
this option is only supported by the upstream protobuf compiler starting
with version 2.5.0. this version is not yet widely available in the
debian/ubuntu repositories, and we would like to avoid breaking the
build on those platforms with the distribution version of protobuf
installed, so revert the following commits:
- 5ee9c03478ea13bba03e7d7edacf723f324200c2
- 84e41e7329f1f0fc09b41ee96e17b28a792cefcf
