Issue #330 is a bug in proto3 behavior and the test case handling it
needs a 'syntax = "proto3";' line in its .proto file, which is not
supported by the protobuf 2 implementation.
Since we still support building against protobuf 2, this commit
conditionalizes the Issue #330 test case so that it is only built when
protobuf-c is being built against protobuf 3.
The scan_length_prefixed_data() function returns the number of bytes
taken up by a varint length delimiter, plus the actual value of that
delimiter. Since it returns a uint32_t, a delimiter of 2^32 - 1 (or
close to that) could cause the return value to overflow and result in an
incorrect value.
At first I tried to fix it by making scan_length_prefixed_data() use a
size_t for its result, but I realized this would have no effect on
32-bit systems. To fix the problem for 32-bit, I changed the function to
return early if the length is 2 GiB or more (protobuf messages are not
allowed to be that large). I kept the size_t change anyway, since the
result will ultimately be stored in a size_t (ScannedMember.len) and we
might as well stay consistent with that.
Signed-off-by: Adam Cozzette <acozzette@google.com>
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>
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.)
this is conditional on whether the linker supports version scripts, for
which we use the gl_LD_VERSION_SCRIPT macro from the gnulib project.
on platforms without version scripts, we fall back to libtool's
-export-symbols-regex.
Still need to add the comments in the source code. Currently I've
seeded it with the libprotobuf-c files. I've configured it
to make man pages and html pages. Might not be ideal, but makes it easy
for me to check things (html is nicer, but man pages are handier for
remote servers).
It’s important to note that, differently from what we’ve seen for
the serial test harness (see Parallel Test Harness), the
AM_TESTS_ENVIRONMENT and TESTS_ENVIRONMENT variables cannot be use
to define a custom test runner; the LOG_COMPILER and LOG_FLAGS (or
their extension-specific counterparts) should be used instead:
## This is WRONG!
AM_TESTS_ENVIRONMENT = PERL5LIB='$(srcdir)/lib' $(PERL) -Mstrict -w
## Do this instead.
AM_TESTS_ENVIRONMENT = PERL5LIB='$(srcdir)/lib'; export PERL5LIB;
LOG_COMPILER = $(PERL)
AM_LOG_FLAGS = -Mstrict -w
(http://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html)
Makefile.am: add valgrind to the AM_TESTS_ENVIRONMENT
configure.ac: enable valgrind testing option for ./configure
m4/valgrind-tests.m4: enable tracing children for libtool wrapper
script compatibility, but ignore standard binaries in /usr or /bin
there's not much point to having the "private" definitions split out
into a separate header file. they're still in the namespace and there's
nothing that can be done to prevent "unauthorized" uses. just integrate
the definitions into the main header file but put them in the bottom and
note that they're "private".
this makes it very slightly easier to copy the protobuf-c support
library into another project wholesale, since one less file is required.
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.
