This commit fixes#251, which causes incorrect code to be generated when
there are multiple oneofs in the same message.
In #221, we added code to force int-sizing for oneof enums, but we only
set vars["opt_comma"] initially, before entering the loop over the
message's oneofs. This caused commas to be omitted when generating the
enums for subsequent oneofs after the first oneof.
This commit resets vars["opt_comma"] every time through the loop that
generates the enum declarations for the message's oneofs.
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.
This tells CMake to refer to the currently executed `CMakeLists.txt`'s directory instead of the root project directory. This allows protobuf-c to be included as a subdirectory (via `include_subdirectory`) while being innocuous for those that build protobuf-c by itself.
This is a first cut at adding proto3 support.
As far as I understand protobuf-c already has pretty much everything
needed once it is built using a new version of protobuf itself.
The only missing thing is that in proto3 all fields are optional and
having to manually set has_foo is inconvenient.
This patch special cases the proto3 syntax files so that structs for the
bytes, enum and primitive fields do not emit the has_ field.
It also adds PROTOBUF_C_LABEL_NONE to the label enum that is used for
proto3 fields. When a fields has this label, the quantifier is not
consulted and instead the field is packed/unpacked depending on
whether it has a value different from NULL/0.
remove .pb.{cc,h} in distdir instead of top_distdir in order to
prevent removing files from other projects when protobuf-c is
included as an autotools subproject.
Signed-off-by: Gregory Detal <gregory.detal@tessares.net>
From https://developers.google.com/protocol-buffers/docs/proto#optional:
If the default value is not specified for an optional element, a
type-specific default value is used instead: for strings, the default
value is the empty string. For bools, the default value is false. For
numeric types, the default value is zero. For enums, the default value
is the first value listed in the enum's type definition. This means care
must be taken when adding a value to the beginning of an enum value
list.
Prior to this change, protoc-c set the default enum value to 0, whether
or not 0 was the first value listed in the enum's type definition (or if
it even was listed at all).
