Ironically, we need to tell automake to distribute the CMakeLists.txt
file in the tarball...

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.

Build with the latest protobuf release, in preparation for adding
"oneof" support.

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

According to the travis-ci documentation, VMs are executed with 1.5
virtual CPU cores, so this should speed up our builds a little bit.

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

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.