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.
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).
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
Adds support for the LITE_RUNTIME optimization option to the protobuf-c
compiler. Enabling this option would generate lighter weight message,
enum, and service descriptors that contain NO strings. As a result,
calls to lookup descriptors via the *_get_{field,value,method}_by_name
API will return NULL.
Default compiler behavior (when optimize_for is not specified or is not
set to LITE_RUNTIME) is unchanged.
Certain protobuf comments could generate invalid C comments
and inadvertently close the comment block. This commit removes '/'
signs in such comments.
One example of a .proto file containing such comments is a commonly
included descriptor.proto from the protobuf library.
warning: assigning to 'uint8_t *' (aka 'unsigned char *')
from 'char *' converts between pointers to integer types
with different sign [-Wpointer-sign]
Add a field flag and functions to pack/unpack oneofs
Add logic to parse multiple fields for the same oneof
Add logic for merging submessages that contain oneofs
For certain platforms where autotools is not the preferred build system,
provide a fallback cmake file that can compile protoc-c and a static
library of libprotobuf-c.
Based on the file from alex85k's protobuf-c repository.
(Issue #168.)
The object file name is not what is expected when building with
automake's "subdir-objects" option. Rather than expecting automake to
generate a specific filename, we simply make the generated header a
dependency of all objects for cxx-generate-packed-data.
(Issue #156, #169.)
Per http://msdn.microsoft.com/en-us/library/z8y1yy88(v=vs.71).aspx,
Microsoft compilers do not support the Standard C keyword 'inline',
instead preferring the implementation-specific '__inline', so add a
workaround for these specific compilers.
Based on a patch from alex85k (#167).
Per the protobuf developers,
We will from everything away from Google Code eventually. We haven't
decided where to put future release packages yet but as it seems github
supports this well chances are we'll use github as the canonical location
for all downloads.
gcc silently treats arithmetic on a void pointer as char pointer
arithmetic without -pedantic. Other compilers do not. Make it explicit
that we are doing arithmetic on a pointer with object size 1.
This eliminates the following diagnostic:
protobuf-c/protobuf-c.c: In function 'parse_packed_repeated_member':
protobuf-c/protobuf-c.c:2404:34: warning: pointer of type 'void *' used in arithmetic [-Wpedantic]
void *array = *(void **) member + siz * (*p_n);
(I did not find any other instances of 'void *' arithmetic when
compiling with -pedantic.)
Based on a patch from alex85k (#167).
If we are not building on gcc, PROTOBUF_C__DEPRECATED needs to be
defined but empty. Previously we were not defining it at all in certain
situations, which would cause build failures.
Based on a patch from alex85k (#167).
