libraries should never generate output on their own to stdout/stderr.
remove the PRINT_UNPACK_ERRORS macro and rename UNPACK_ERROR to
PROTOBUF_C_UNPACK_ERROR.
the error strings are left in but compiled out by default. they could
theoretically be re-enabled for a debugging session by changing the
PROTOBUF_C_UNPACK_ERROR macro to something like:
#define PROTOBUF_C_UNPACK_ERROR(...) do { fprintf(stderr, __VA_ARGS__); fputc('\n', stderr); } while (0)
some of these headers aren't used in the protobuf-c code base any more,
and in any case the results of these checks (the HAVE_*_H defines in
config.h) are not actually used anywhere and the absence of any of these
headers doesn't cause configure to fail, so just delete these useless
checks.
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.
in general, libraries shouldn't be responsible for terminating the
program if memory allocation fails. if we need to allocate memory and
can't, we should be returning a failure indicator, not providing a
strange interface to the user for receiving a callback in the event of
such an error.
also in general, libraries should never write to stdout or stderr.
this breaks the API/ABI and will require a note in the ChangeLog.
i'm confused as to why these fields exist, since the typical
implementation of a "temporary alloc" would be something like alloca(),
and alloca() is usually just inlined code that adjusts the stack
pointer, which is not a function whose address could be taken.
this breaks the API/ABI and will require a note in the ChangeLog.
possibly we could revisit the idea of "temporary allocations" by using
C99 variable length arrays. this would have the advantage of being
standardized, unlike alloca().
this should silence Coverity #1153648, which complains because
tmp.length_prefix_len is uninitialized for certain wire types when
copied on line 2486:
scanned_member_slabs[which_slab][in_slab_index++] = tmp;
dave's original style drives me crazy. reformat the C code in
protobuf-c/ with "indent -kr -i8" and manually reflow for readability.
try to fit most lines in 80 columns, but due to the lengthy type and
function names in protobuf-c, enforcing an 80 column rule would result
in a lot of cramped statements, so try to fit lines in up to 100 columns
if it would improve readability. (e.g., one <=100 column line is
probably better than 3-4 <=80 column lines.)
ultimately i'd like to adopt most of the recommendations in the linux
coding style: https://www.kernel.org/doc/Documentation/CodingStyle.
this commit gets us most of the kernel indentation and comment coding
style recommendations. later commits will tackle style recommendations
that require more intrusive changes: breaking up large functions,
replacing macros that affect control flow (e.g., DO_ALLOC). this will
hopefully facilitate review and make the code base easier to maintain.
i ran the old and new versions of protobuf-c.c through something like:
gcc -S -D__PRETTY_FUNCTION__=0 -D__FILE__=0 -D__LINE__=0 -Wall -O0 \
-o protobuf-c.S -c protobuf-c.c
and reviewed the diffs of the assembly output to spot any functions that
changed, and went back to make sure that any differences were
functionally equivalent.
of the same field on the wire (Fixes#91)
t/generated-code2/test-generated-code2.c: add a test case for merging
messages
t/test-full.proto: expand message definitions to test for merging nested
messages
per https://code.google.com/p/protobuf/source/detail?r=50, the license
on google-originated protobuf code was switched from Apache-2.0 to
BSD-3-Clause (so-called "New BSD" license). update any of the google
license statements to use this new license.
per email with dave, drop the third clause on his BSD-3-Clause license,
so this now becomes BSD-2-Clause.
make sure to use consistent indentation and wrapping throughout.
the change that required protobuf >= 2.5.0 has been reverted, so there's
no need to build protobuf from source. use the system protobuf packages
instead.
also use distcheck to build and check the distribution. this will run
the test suite and perform various other checks. it will also perform a
VPATH build using the distribution tarball, which will catch any files
present in the git repository but inadvertently not distributed in the
tarball.
also test the build when configured with "--enable-rpc".
for some reason, "make distcheck" fails when the build is configured
with --disable-protoc. i haven't been able to track down the root cause
(it appears the build is trying to generate the generated pb-c files for
the test cases, but the test cases should be disabled when
--disable-protoc is specified). so, remove the --disable-protoc option.
libprotobuf-c should always be tested as part of a build, and this can't
be done unless protoc-c is built. this also reduces the number of build
combinations that need to be tested.
this option is only supported by the upstream protobuf compiler starting
with version 2.5.0. this version is not yet widely available in the
debian/ubuntu repositories, and we would like to avoid breaking the
build on those platforms with the distribution version of protobuf
installed, so revert the following commits:
- 5ee9c03478ea13bba03e7d7edacf723f324200c2
- 84e41e7329f1f0fc09b41ee96e17b28a792cefcf
Fixed Issue #63, which was introduced when
"required" fields were verified. (Introduced in protobuf-c 0.14)
git-svn-id: https://protobuf-c.googlecode.com/svn/trunk@322 00440858-1255-0410-a3e6-75ea37f81c3a
