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).
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.
In order to add compatibility with the latest protobuf 2.6.0 release, we
need to add an option to the t/test-full.proto schema that was
introduced in protobuf 2.5.0, so we need to depend on protobuf 2.5.0 or
higher now.
This should fix the following build failure.
./protoc-c/protoc-c: error while loading shared libraries: libprotobuf.so.8: cannot open shared object file: No such file or directory
make: *** [t/test.pb-c.c] Error 127
It turns out that in YAML,
language: c
language: cpp
Actually means:
language: cpp
I'm not sure if travis-ci actually supports providing a list of values
for the 'language' parameter, but let's try it anyway.
The travis-ci environment is based on Ubuntu 12.04 LTS, which has an
older protobuf version (2.4.1). We need to depend on features that are
only available in 2.5.0 (and, later, 2.6.0), so instead of satisfying
the protobuf build dependencies from the Ubuntu repository, download and
install our own copy of protobuf.
The travis-ci build from this commit should succeed, since we are
compatible with protobuf 2.5.0.
Based on a patch from Ilya Lipnitskiy.
in the case that we are unpacking a 0-length byte string, we need to
explicitly set bd->data to NULL, otherwise we may try to free() a stray
pointer when protobuf_c_message_free_unpacked() is called on the
containing message.
(Issue #157.)
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
This reverts commit e7dc76c54bf5869247ec0a330ae9cf7f5499154d.
i really dislike cluttering up files with editor-specific modelines, and
anyway the //-comments run afoul of #124.
"protobuf_c_default_allocator" is the last bit of global data in
libprotobuf-c, and it can be hidden with some relatively easy (though
API/ABI-breaking) changes to ProtobufCBufferSimple.
all exported functions that take a ProtobufCAllocator either use the
provided allocator (if non-NULL), or switch to the default allocator (if
NULL). there are now two relatively unambiguous choices when a
ProtobufCAllocator is required by an exported function:
1) use NULL. the vast majority of callers should pick this option.
2) implement your own allocation functions, and enclose these in a
ProtobufCAllocator struct.
in previous versions of protobuf-c there were two other possibilities:
3) maybe use &protobuf_c_system_allocator?
4) maybe use &protobuf_c_default_allocator?
this was relatively confusing, and by removing these latter two options
we can avoid having global library state.
identifiers that begin with an underscore are reserved. instead, use a
double underscore in the *middle* of the identifier to indicate that
it's an "internal" identifier.
this is the completely unmodified output output from running
"doxygen -g Doxyfile.in". (note that this is doxygen 1.8.7.)
customization will come in a subsequent commit so that we have a record
of exactly what was changed from the default values.
exact version coupling between the compiler and the public headers is
too strict because some existing projects (such as collectd,
riemann-c-client, and nmsg) directly embed .pb-c.h files generated by
protoc-c into their exported headers. this would cause unnecessary build
failures in downstream clients of these libraries if a newer version of
the protobuf-c headers is installed.
however, it's still desireable to be able to explicitly declare when
compatibility is broken between the headers and the compiler, so
introduce new variables that allow independently setting the minimum
header version required by the compiler and the minimum compiler version
required by the header.
this follows the protobuf C++ implementation a little bit more closely,
though we don't have an analogous facility for verifying that the header
and *library* are compatible. (this seems like overkill for a C project;
in practice the headers and the library will be from the same version,
especially in downstream distributors like debian where the -dev package
has an exact versioned dependency on the shared library package.)
this adds a version guard like the protobuf C++ implementation. it
ensures that protoc-c and <protobuf-c.h> are from the exact same version
of protobuf-c.
this replaces the changes in Issue #53 with a slightly different way of
representing / retrieving the version number.
protobuf_c_version() returns the version of the *library* as a string.
protobuf_c_version_number() returns the version of the *library* as an
integer.
PROTOBUF_C_VERSION is the version of the *headers* as a string constant.
PROTOBUF_C_VERSION_NUMBER is the version of the *headers* as an integer.
rename PROTOBUF_C_FIELD_FLAGS_PACKED to PROTOBUF_C_FIELD_FLAG_PACKED.
rename ProtobufCFieldFlagType to ProtobufCFieldFlag.
wrap some particular long lines.
update documentation.
for clarity, use a "uint32_t" instead of "unsigned" for the 'flags'
field in _ProtobufCFieldDescriptor.
Originally, someone complained about protobuf_c_message_unpack() using
alloca() for the allocation of the temporary bitmap used to detect that
all required fields were present in the unpacked message (Issue #60).
Commit 248eae1d eliminated the use of alloca(), replacing the
variable-length alloca()'d bitmap with a 16 byte stack-allocated bitmap,
treating field numbers mod 128.
Andrei Nigmatulin noted in PR #137 problems with this approach:
Apparently 248eae1d has introduced a serious problem to protobuf-c
decoder.
Originally the function of required_fields_bitmap was to prevent
decoder from returning incomplete messages. That means, each
required field in the message either must have a default_value or be
present in the protobuf stream. The purpose of this behaviour was to
provide user with 100% complete ProtobufCMessage struct on return
from protobuf_c_message_unpack(), which does not need to be checked
for completeness just after. This is exactly how original protobuf
C++ decoder behaves. The patch 248eae1d broke this functionality by
hashing bits of required fields instead of storing them separately.
Consider a protobuf message with 129 fields where the first and the
last fields set as 'required'. In this case it is possible to trick
decoder to return incomplete ProtobufCMessage struct with missing
required fields by providing only one of the two fields in the
source byte stream. This can be considered as a security issue as
well because user's code do not expect incomplete messages with
missing required fields out from protobuf_c_message_unpack(). Such a
change could introduce undefined behaviour to user programs.
This patch is based on Andrei's fix and restores the exact detection of
missing required fields, but avoids doing a separate allocation for the
required fields bitmap except for messages whose descriptors define a
large number of fields. In the "typical" case where the message
descriptor has <= 128 fields we can just use a 16 byte array allocated
on the stack. (Note that the hash-based approach also used a 16 byte
stack allocated array.)
