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.

most of the relevant material has now been updated and incorporated into
the doxygen documentation.

based heavily on kevin lyda's work in PR #140.

partially based on hunks split out of kevin lyda's PR #140.

this also significantly reorganizes the header file.

based heavily on kevin lyda's work in PR #140.

these identifiers aren't intended for use by client code. add a double
underscore to indicate this.

this identifier isn't intended for use by client code. add a double
underscore to indicate this.

these identifiers aren't intended for use by client code. add a double
underscore to indicate this.

offsetof() conforms to the C89 standard, just call it directly.

identifiers in any scope that begin with an underscore and a capital
letter are reserved in C.

these magic constants aren't intended for use by client code. add a
double underscore to indicate this.

assert() conforms to the C89 standard, just call it directly.

this macro isn't used anywhere except in the libprotobuf-c
implementation.

this avoids littering function definitions in the documentation with
"PROTOBUF_C_API".

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.

identifiers that begin with a double underscore are reserved.