- 24 Nov, 2014 3 commits
-
-
Robert Edmonds authored
-
Robert Edmonds authored
-
Robert Edmonds authored
-
- 20 Nov, 2014 4 commits
-
-
Ilya Lipnitskiy authored
Add test cases for parsing multiple fields of the same oneof from the wire Add more tests for submessage merging, including oneofs
-
Ilya Lipnitskiy authored
-
Ilya Lipnitskiy authored
-
Ilya Lipnitskiy authored
Add a field flag and functions to pack/unpack oneofs Add logic to parse multiple fields for the same oneof Add logic for merging submessages that contain oneofs
-
- 19 Nov, 2014 1 commit
-
-
Ilya Lipnitskiy authored
-
- 15 Nov, 2014 2 commits
-
-
Ilya Lipnitskiy authored
-
Ilya Lipnitskiy authored
-
- 12 Sep, 2014 1 commit
-
-
Robert Edmonds authored
-
- 10 Sep, 2014 1 commit
-
-
Robert Edmonds authored
-
- 08 Sep, 2014 6 commits
-
-
Robert Edmonds authored
-
Robert Edmonds authored
-
Robert Edmonds authored
Ironically, we need to tell automake to distribute the CMakeLists.txt file in the tarball...
-
Robert Edmonds authored
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.)
-
Natanael Copa authored
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.)
-
Robert Edmonds authored
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).
-
- 05 Sep, 2014 11 commits
-
-
Robert Edmonds authored
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.
-
Robert Edmonds authored
Build with the latest protobuf release, in preparation for adding "oneof" support.
-
Robert Edmonds authored
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).
-
Robert Edmonds authored
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).
-
Robert Edmonds authored
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.
-
Robert Edmonds authored
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.
-
Robert Edmonds authored
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.
-
Robert Edmonds authored
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
-
Robert Edmonds authored
-
Robert Edmonds authored
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.
-
Robert S. Edmonds authored
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.
-
- 03 Sep, 2014 1 commit
-
-
Robert S. Edmonds authored
-
- 05 Aug, 2014 3 commits
-
-
Robert Edmonds authored
-
Robert Edmonds authored
-
Robert Edmonds authored
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.)
-
- 22 Jul, 2014 3 commits
-
-
Robert Edmonds authored
-
Robert Edmonds authored
-
Robert Edmonds authored
-
- 15 Jul, 2014 1 commit
-
-
Robert Edmonds authored
-
- 30 Jun, 2014 1 commit
-
-
Andrei Nigmatulin authored
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
-
- 27 Jun, 2014 2 commits
-
-
Robert Edmonds authored
-
Robert Edmonds authored
-