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 e7dc76c54bf5869247ec0a330ae9cf7f5499154d.
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.
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.
this is the completely unmodified output output from running
"doxygen -g Doxyfile.in". (note that this is doxygen 1.8.7.)
customization will come in a subsequent commit so that we have a record
of exactly what was changed from the default values.
exact version coupling between the compiler and the public headers is
too strict because some existing projects (such as collectd,
riemann-c-client, and nmsg) directly embed .pb-c.h files generated by
protoc-c into their exported headers. this would cause unnecessary build
failures in downstream clients of these libraries if a newer version of
the protobuf-c headers is installed.
however, it's still desireable to be able to explicitly declare when
compatibility is broken between the headers and the compiler, so
introduce new variables that allow independently setting the minimum
header version required by the compiler and the minimum compiler version
required by the header.
this follows the protobuf C++ implementation a little bit more closely,
though we don't have an analogous facility for verifying that the header
and *library* are compatible. (this seems like overkill for a C project;
in practice the headers and the library will be from the same version,
especially in downstream distributors like debian where the -dev package
has an exact versioned dependency on the shared library package.)
