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.)
