09b801a968
this reworks memory allocation throughout the support library.
the old DO_ALLOC macro had several problems:
1) only by reading the macro implementation is it possible to tell
what actually occurs. consider:
DO_ALLOC(x, ...);
vs.:
x = do_alloc(...);
only in the latter is it clear that x is being assigned to.
2) it looks like a typical macro/function call, except it alters the
control flow, usually by return'ing or executing a goto in the
enclosing function. this type of anti-pattern is explicitly called out
in the linux kernel coding style.
3) in one instance, setting the destination pointer to NULL is
actually a *success* return. in parse_required_member(), when parsing
a PROTOBUF_C_TYPE_BYTES wire field, it is possible that the field is
present but of zero length, in which case memory shouldn't be
allocated and nothing should actually be copied. this is not apparent
from reading:
DO_ALLOC(bd->data, allocator, len - pref_len, return 0);
memcpy(bd->data, data + pref_len, len - pref_len);
instead, make this behavior explicit:
if (len - pref_len > 0) {
bd->data = do_alloc(allocator, len - pref_len);
if (bd->data == NULL)
return 0;
memcpy(bd->data, data + pref_len, len - pref_len);
}
this is much more readable and makes it possible to write a
replacement for DO_ALLOC which returns NULL on failures.
this changes the protobuf_c_default_allocator to contain only NULL
values; if a replacement function pointer is not present (non-NULL) in
this struct, the default malloc/free implementations are used. this
makes it impossible to call the default allocator functions directly and
represents an API/ABI break, which required a fix to the
PROTOBUF_C_BUFFER_SIMPLE_CLEAR macro.
despite turning one-line allocations in the simple case:
DO_ALLOC(rv, allocator, desc->sizeof_message, return NULL);
into three-line statements like:
rv = do_alloc(allocator, desc->sizeof_message);
if (!rv)
return (NULL);
this changeset actually *reduces* the total number of lines in the
support library.
Overview
This is protobuf-c, a C implementation of Google Protocol Buffers. It includes libprotobuf-c, a pure C library that implements protobuf encoding and decoding, and protoc-c, a code generator that converts Protocol Buffer .proto files to C descriptor code, based on the original protoc. protobuf-c formerly included an RPC implementation; that code has been split out into the protobuf-c-rpc project.
protobuf-c was originally maintained by Dave Benson through version 0.15 but is now being maintained by a new team. Thanks, Dave!
Building
protobuf-c requires a C compiler, a C++ compiler, Google Protocol Buffers, and pkg-config to be installed.
./configure && make && make install
If building from a git checkout, the autotools (autoconf, automake, libtool) must also be installed, and the build system must be generated by running the autogen.sh script.
./autogen.sh && ./configure && make && make install
Synopsis
Include the protobuf-c header file:
#include <protobuf-c/protobuf-c.h>
Link against the protobuf-c library.
-lprotobuf-c
libprotobuf-c includes a pkg-config file. It is recommended to use the pkg-config system in order to determine the complete set of compiler and linker flags for building applications that utilize libprotobuf-c. If using pkg-config with autoconf, the PKG_CHECK_MODULES macro can be used to detect the presence of libprotobuf-c:
PKG_CHECK_MODULES([PROTOBUF_C], [libprotobuf-c])
This will place compiler flags in the PROTOBUF_C_CFLAGS variable and linker flags in the PROTOBUF_C_LDFLAGS variable.
(Note that the protobuf-c header file used to be installed as google/protobuf-c/protobuf-c.h in previous versions.)
Contributing
Please send patches to the protobuf-c mailing list or by opening a GitHub pull request.
Copyright to all contributions are retained by the original author, but must be licensed under the terms of the BSD-2-Clause license. Please add a Signed-off-by header to your commit message (git commit -s) to indicate that you are licensing your contribution under these terms.