digideskio / protobuf-c Goto Github PK

Recently, a crashing bug was reported from a user. The cause happened to be
a corrupted protobuf-encoded data file.

To reproduce the issue, as well as check for any others, we used zzuf
(http://caca.zoy.org/wiki/zzuf) to fuzz input  to the protobuf-c decoder.

With this, we were able to find and work-around a number of decoding
issues. I've attached a small project containing an isolated version of
this fuzz testcase.

What steps will reproduce the problem?
1) Build and run the provided fuzzing test case using 'make'
2) This will trigger a number of reproducible issues.

What is the expected output? What do you see instead?
Decoding should fail, and the process should exit gracefully. Instead,
decoding crashes in a number of locations:

- Protobuf group wiretypes trigger an assert() in the decoding code.
- If decoding of a message field fails, later fields may not be fully
initialized, and deallocation will fail
- Deallocation is attempted on uninitialized repeated fields

Our fixes for these issues are available here:

http://code.google.com/p/plcrashreporter/source/detail?r=235&path=/trunk/Depende
ncies/protobuf-2.0.3/src/protobuf-c.c
http://code.google.com/p/plcrashreporter/source/detail?r=263&path=/trunk/Depende
ncies/protobuf-2.0.3/src/protobuf-c.c

I'd be most appreciative of your review!

What version of the product are you using? On what operating system?

protobuf-c 0.7 on Mac OS X 10.5.5

on big endian platforms the protobuf-c test suite fails, e.g.:

> Test: test required sfixed32... test_versus_static_array failed:
> actual: [length=6]
>  a5 06 70 a7 bf bf
> expected: [length=6] [buffer test_required_sfixed32_min]
>  a5 06 00 00 00 80
> at line 235 of test-generated-code2.c.

or

> Test: test required sfixed32... test_versus_static_array failed:
> actual: [length=6]
>  a5 06 48 60 43 00
> expected: [length=6] [buffer test_required_sfixed32_min]
>  a5 06 00 00 00 80
> at line 235 of test-generated-code2.c.

or

> Test: test required sfixed32... Bus error

the problem is that required_field_pack_to_buffer() attempts to 
dereference the void *member parameter as a uint64_t pointer when member 
points to a 32 bit quantity. this happens to work on little endian 
platforms but not on big endian platforms.

the attached patch fixes this.

What steps will reproduce the problem?

test.c:

#include <google/protobuf-c/protobuf-c.h>
#include "addressbook.pb-c.h"

int main()
{
    Tutorial__Person *p;
    const uint8_t *data = "";

    p = tutorial__person__unpack(0, 0, data);

    return p == NULL;
}

This example should return exit code 1, because required field "name" is 
missing. This behaviour seems to be correct, because c++ version of protobuf 
does the same.

Here is output of this code:

> ./a.out ; echo $?
0

Here is output of the same code with patch applied:

> ./a.out ; echo $?
message 'tutorial.Person': missing required field 'name'
1

What steps will reproduce the problem?
1. Build protobuf-c with protobuf 2.0.1

What is the expected output? What do you see instead?
There is an error in dump_test_unknown_fields when calling
mess.GetReflection() - apparently this function signature changed from
2.0.0beta to 2.0.1

What version of the product are you using? On what operating system?
protobuf-c 0.3, protobuf 2.0.1, Fedora Core 9

Please provide any additional information below.

Quantifier offset comment in C files is declared in the C++ style.  Please
change to C syntax.  (i.e., /* .. */ )

Thanks!

The FREE function is never called inside of "protobuf_c_message_unpack" when 
unpacking a protocol buffer, causing a memory leak. I am debugging using IAR 
Embedded Workbench and programming a TI MSP430F247.

protobuf-c uses a flexible pluggable allocator scheme to permit clients of
the library to adapt it to any kind of memory allocator. There is also a
hook allowing the standard allocator's response to allocation failure to be
customized. Unfortunately, this flexibility is of limited use because the
uses of the allocator in the protobuf-c library don't check for allocation
failure, meaning that the default behavior of aborting when out of memory
is pretty much the only available option.

For my project I needed robustness against alloc failure, and aborting the
program is not acceptable. The attached patch tries to make it so that all
calls into the protobuf-c lib either complete all allocations successfully,
or unwind all partial allocations and return NULL. Please consider it for
inclusion in the standard protobuf-c distribution.

Two unit tests were added to test the new behavior, but they don't yet
cover all allocation code paths in library.

Within the attacked .zip file is a script 'mk' and related sources
that reproduce the issue on my machine.
It does so in the context of reading a message streamed by Python code but
I don't think that is essential.

What version of the product are you using? On what operating system?
-0.0

Please provide any additional information below.

What steps will reproduce the problem?
1. Install mingw compiler from ubuntu repository, build and install 
protobuf.
2. Now, I'm trying to configure protobuf-c
./configure --prefix=/usr/i586-mingw32msvc --host=i586-mingw32msvc
3. then build protobuf-c (see notes about LDFLAGS below)
make LDFLAGS=-no-undefined

What is the expected output? What do you see instead?
Instead of successful build process, compiler reports errors about header 
files alloca.h and sys/poll.h. There are no such files in mingw include 
directory. alloca.h solved with ln -s malloc.h alloca.h, but it seems 
sys/poll.h haven't equivalent in mingw.

What version of the product are you using? On what operating system?
I'd tried with 0.9 and 0.10 version of protobuf-c. I've used Ubuntu 8.10 
and mingw installation from it's official repository.

Please provide any additional information below.
protobuf and protobuf-c also has troubles with building shared libraries 
with mingw, it's solved with LDFLAGS according to http://www.mail-
archive.com/[email protected]/msg09482.html

1. include directory in installed tree contains 'protobufc' but generated
files want protobuf-c
2. ./configure does not seem to check for google protobuf package
installation. Also would be nice if one could point ./configure to a
specific google protobuf installation tree.

What steps will reproduce the problem?
1. build + installation + use
2. build

What is the expected output? What do you see instead?
1. compile of generated code fails
2. make fails

What version of the product are you using? On what operating system?
-0.0

Please provide any additional information below.
Redhat, Linux

What steps will reproduce the problem?
1. Make project and compile on Visual Studio 2008.
2. Get compilation errors due to MS incompatibilities with POSIX.
3.

What is the expected output? What do you see instead?
Errors.

What version of the product are you using? On what operating system?
0.13. WinXP SP3.

Please provide any additional information below.

* snprintf not supported. Use _snprinf.

What steps will reproduce the problem?
1. checkout protobuf-c-0.11 (or svn upstream)
2. run the ./bootstrap && ./configure && make
3. get this compilation error:

g++ -DPACKAGE_NAME=\"protobuf-c\" -DPACKAGE_TARNAME=\"protobuf-c\" -
DPACKAGE_VERSION=\"0.11\" -DPACKAGE_STRING=\"protobuf-c\ 0.11\" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"protobuf-c\" -DVERSION=\"0.11\" -
DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DHAVE_INTTYPES_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_SELECT_H=1 -
DHAVE_ALLOCA_H=1 -DHAVE_MALLOC_H=1 -DPROTOC_VERSION=2002000 -
DHAVE_ENDIAN_H=1 -DIS_LITTLE_ENDIAN=1 -I.     -g -O2 -MT c_enum_field.o -MD 
-MP -MF .deps/c_enum_field.Tpo -c -o c_enum_field.o `test -f 
'google/protobuf/compiler/c/c_enum_field.cc' || echo 
'./'`google/protobuf/compiler/c/c_enum_field.cc
google/protobuf/compiler/c/c_enum_field.cc:26:45: error: 
google/protobuf/wire_format_inl.h: No such file or directory
google/protobuf/compiler/c/c_enum_field.cc:33: error: 
‘google::protobuf::internal::WireFormat’ has not been declared
make[2]: *** [c_enum_field.o] Error 1

What version of the product are you using? On what operating system?
protobuf-c-0.11 (probably all versions)
ptotobuf-2.2.0 (from fedora rpm)
OS: fedora 11, x86_64

What steps will reproduce the problem?
1. Run protoc-c on any valid proto file

What is the expected output? What do you see instead?
I expect no C++ style comments. (i.e., no comments beginning with "//")

What version of the product are you using? On what operating system?
0.2

Please provide any additional information below.
The C++ style comments are being generated at the first and last lines of
every generated .h file, and the first line of every generated .c file.

ProtobufCAllocator should have an alloc_unaligned method used for strings and 
bytes.

Should this method be optional?  Should we have a way for bytes to point at the 
packed buffer?

centos 5.5 64, gcc 4.1 , protobuf 2.2, protobuf-c 1.4

the proto file is like this:

message country {
        required string         name = 1;
        repeated province       provinces = 2;  
}

message province {
        required string         name = 1;
        repeated city           cities = 2;
}

message city {
        required int32          id = 1;
        required string         name = 2;
}

this is my code:

       Country *country = malloc(sizeof(Country));
        country__init(country);

        Province* provinces[2];
        provinces[0] = malloc(sizeof(provinces));
        provinces[1] = malloc(sizeof(provinces));
        province__init(provinces[0]);
        province__init(provinces[1]);

        City* city_a[2];
        city_a[0] = malloc(sizeof(City));
        city_a[1] = malloc(sizeof(City));
        city__init(city_a[0]);
        city__init(city_a[1]);

        city_a[0]->id = 1;
        city_a[0]->name = "city1";
        city_a[1]->id = 2;
        city_a[1]->name = "city2";


        City* city_b[2];
        city_b[0] = malloc(sizeof(City));
        city_b[1] = malloc(sizeof(City));
        city__init(city_b[0]);
        city__init(city_b[1]);

        city_b[0]->id = 3;
        city_b[0]->name = "city3";
        city_b[1]->id = 4;
        city_b[1]->name = "city4";

        provinces[0]->cities = city_a;
        provinces[0]->name = "anhui";
        provinces[1]->cities = city_b;
        provinces[1]->name = "guangdong";
        provinces[0]->n_cities = 2;
        provinces[1]->n_cities = 2;


        country->provinces = provinces;
        country->name = "china";
        country->n_provinces = 2;

        printf("%s \n", country->name);

        size_t size = country__get_packed_size(country);
        char* buffer = malloc(sizeof(char) * size);
        size_t packed_size = country__pack(country, buffer);
        FILE *fp;
        if ((fp = fopen("test.dat", "wb+")) == NULL) 
        {   
                printf("cannt open file");
                exit(1);
        }   
        fwrite(buffer, sizeof(char), packed_size, fp);  
        fclose(fp);

        return 0;

i got error: Segmentation fault

What steps will reproduce the problem?
1. Delcare optional int32 in .proto file.
2. set the optional field.
3. pack it.
4. unpack it.
5. get the optional field.

What is the expected output? What do you see instead?
I was expecting the optional field back. But it is always the default value(0) .

What version of the product are you using? On what operating system?
version: libprotoc 2.3.0
os: fedora core 10

-- Thanks
Kamanashis Roy

What steps will reproduce the problem?
1. Write a program that opens a TCP connection with an RPC service and 
calls a method, but doesn't close the socket
2. Run this program simultaneously more than 8 times

What is the expected output? What do you see instead?
Expected to receive the service to reply to all the instances on the 
program; instead, the service segfaults

What version of the product are you using? On what operating system?
protobuf-c svn196 on various versions of Linux

Please provide any additional information below.
This appears to be because the dispatcher's callbacks array is not 
expanded when the notifies array is. Attached is a patch that seems to 
fix it.

What steps will reproduce the problem?
1. used protobuf-2.3.0
2. used protobuf-c-0.12
3. used Linux, RedHat 5 (2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:28:30 EDT 
2009 x86_64 x86_64 x86_64 GNU/Linux)
4. Run ./configure --prefix=/apps/protobuf-c-0.12 CPPFLAGS=-
I/apps/protobuf-2.3.0/include LDFLAGS=-L/apps/protobuf-2.3.0/lib
5. Note that in DEFS, -DPROTOC_VERSION=0

What is the expected output? What do you see instead?
-DPROTOC_VERSION=2003000 is expected output.
-DPROTOC_VERSION=0 is what is see.
This configuration happens to work on 32 bit, but not on 64 bit with 
protobuf-2.3.0

What version of the product are you using? On what operating system?
protobuf-c-0.12 on Linux RedHat 5 x64

Please provide any additional information below.

src/test/cxx-generate-packed-data.cc needs to #include <stdio.h> for the 
printf prototype in order to compile with gcc 4.4. see http://
bugs.debian.org/cgi-bin/bugreport.cgi?bug=529004 for details.

What steps will reproduce the problem?
1. Call the protobuf_c_rpc_client_set_error_handler function defined in 
protobuf-c-rpc.h
2. Try to build but get a linker error
3. Look at the source code and notice that the function doesn't exist

What is the expected output? What do you see instead?

Build successfully and call the provided handler when an error occurs.

What version of the product are you using? On what operating system?

protobuf-c 0.12 & Ubuntu Linux (Karmic)

Please provide any additional information below.

What steps will reproduce the problem?
1. uncompress  protobuf-c-0.10
2. execute ./configure
3. ./configure fails

What is the expected output? What do you see instead?
I expect a successfull operation message. I see next message:
configure: error:
ERROR:
protobuf test program failed to link:
perhaps you need to add -Llibdir to your LDFLAGS.


What version of the product are you using? On what operating system?
0.10 on Fedora core 5

Please provide any additional information below.

What steps will reproduce the problem?
1. link error when building protoc-c

What is the expected output? What do you see instead?
Numerous link errors.  I believe line 230 in src/Makefile needs -lprotobuf
added to it 

What version of the product are you using? On what operating system?
Protobuf 2.0.1 and Protobuf-C 0.3

Please provide any additional information below.

[deleted issue]

test-rpc hangs on big endian platforms (tested sparc and s390).

$ make check
[...]
testing local service
creating client
verify client cannot connect
testing unconnected client
creating server
waiting to connect
testing client

^Cmake[4]: *** [check-TESTS] Interrupt
make[3]: *** [check-am] Interrupt
make[2]: *** [check] Interrupt
make[1]: *** [check-recursive] Interrupt
make: *** [check-recursive] Interrupt

What steps will reproduce the problem?
1. download protobuf-c-0.13
2. ./configure
3.

What is the expected output? What do you see instead?
checking google/protobuf/stubs/common.h usability... no
checking google/protobuf/stubs/common.h presence... no
checking for google/protobuf/stubs/common.h... no
configure: error:
  ERROR: protobuf headers are required.

  You must either install protobuf from google,
  or if you have it installed in a custom location
  you must add '-Iincludedir' to CXXFLAGS
  and '-Llibdir' to LDFLAGS.

google/protobuf/stubs/common.h   Download file not found it

configure: error:
  ERROR:
  protobuf test program failed to link:
  perhaps you need to add -Llibdir to your LDFLAGS.

./configure CXXFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib 
LDFLAGS=-lpthread 

fails too!

What version of the product are you using? On what operating system?
[root@localhost protobuf-c-0.13]# gcc -v
 specs。
Tag：i386-redhat-linux
config：../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk 
--disable-dssi --enable-plugin 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic 
--host=i386-redhat-linux
thread mode：posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)


Please provide any additional information below.

What steps will reproduce the problem?
1. download protobuf-c 0.13
2.
3.

What is the expected output? What do you see instead?
svn/ trunk/src/google/protobuf/compiler/c/main.cc file include "#include 
<google/protobuf/compiler/command_line_interface.h>
"

command_line_interface.h not found


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1.
test rpc example, server on ppc,client on x86.
input dave,no response. 
2.
write a prog use uint32_to_le():

#include <stdint.h>
uint32_to_le (uint32_t le)
{
  return (le << 24) | (le >> 24)
       | ((le >> 8) & 0xff0000)
       | ((le << 8) & 0xff00);
}
main()
{
        printf("%x %x",0x01020304,uint32_to_le(0x01020304));
}

result is:
1020304 4010401

change to:
       | ((le >> 8) & 0xff00)
       | ((le << 8) & 0xff0000);

result is:
1020304 4030201

3.
fix google/protobuf-c/protobuf-c-rpc.c
compile.
run step 1,
ok

What steps will reproduce the problem?
1. Compile the following proto file:
-----
package test;

message TestMessage {
    required string str = 1;
}

service Test {
    rpc testMethod(TestMessage) returns (TestMessage);
}
----

protoc-c Test.proto --c_out=.

2. Compile the resulting Test.pb-c.c
gcc -Wall Test.pb-c.c -c

What is the expected output? What do you see instead?
Expecting compilation w/o warnings
gcc gives warning
Test.pb-c.c:100: warning: initialization discards qualifiers from pointer 
target type
Unfortunately under IAR Embedded workbench for ARM the same line causes 
error, not warning.

What version of the product are you using? On what operating system?
protobuf-c 0.10 w/libprotobuf-2.0.3, gcc 4.4.0

Please provide any additional information below.
Attaching patch

What steps will reproduce the problem?
1. Install Fedora 11 + updates
2. Install protobuf* packages
3. ./configure ; make

What is the expected output?
successful build

What do you see instead?
The following build output:

if g++ -DPACKAGE_NAME=\"protobuf-c\" -DPACKAGE_TARNAME=\"protobuf-c\"
-DPACKAGE_VERSION=\"0.11\" -DPACKAGE_STRING=\"protobuf-c\ 0.11\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"protobuf-c\" -DVERSION=\"0.11\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_SYS_POLL_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_ALLOCA_H=1
-DHAVE_MALLOC_H=1 -DPROTOC_VERSION=2002000 -DHAVE_ENDIAN_H=1
-DIS_LITTLE_ENDIAN=1 -I. -I.     -g -O2 -MT c_enum_field.o -MD -MP -MF
".deps/c_enum_field.Tpo" -c -o c_enum_field.o `test -f
'google/protobuf/compiler/c/c_enum_field.cc' || echo
'./'`google/protobuf/compiler/c/c_enum_field.cc; \
    then mv -f ".deps/c_enum_field.Tpo" ".deps/c_enum_field.Po"; else rm -f
".deps/c_enum_field.Tpo"; exit 1; fi
google/protobuf/compiler/c/c_enum_field.cc:26:45: error:
google/protobuf/wire_format_inl.h: No such file or directory
google/protobuf/compiler/c/c_enum_field.cc:33: error:
‘google::protobuf::internal::WireFormat’ has not been declared
make[2]: *** [c_enum_field.o] Error 1
make[2]: Leaving directory `/spare/tmp/protobuf-c-0.11/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/spare/tmp/protobuf-c-0.11/src'
make: *** [all-recursive] Error 1


What version of the product are you using? On what operating system?
protobuf-c-0.11.tar.gz

Fedora 11/x86-64

Please provide any additional information below.

[jgarzik@bd protobuf-c-0.11]$ rpm -qa | grep protob | sort
protobuf-2.2.0-2.fc11.x86_64
protobuf-compiler-2.2.0-2.fc11.x86_64
protobuf-devel-2.2.0-2.fc11.x86_64
protobuf-lite-2.2.0-2.fc11.x86_64
protobuf-lite-devel-2.2.0-2.fc11.x86_64

What steps will reproduce the problem?
1. uncompress  protobuf-c-0.10
2. execute ./configure
3. ./configure fails

What is the expected output? What do you see instead?
configure: error:
ERROR:
 You must either install protobuf from google,
  or if you have it installed in a custom location
  you must add '-Iincludedir' to CXXFLAGS
  and '-Llibdir' to LDFLAGS.


What version of the product are you using? On what operating system?
protobuf-c 0.13 on Free BSD

Please provide any additional information below.

What steps will reproduce the problem?
My proto file has an enum followed by a message which has a field with that
enum. The generated code will not compile.

What is the expected output? What do you see instead?
The generate .h file has the enum defined in the 'descriptors' section of
the .h file.
Compiles fail if the enum is used in e.g. the messages section (enum-typed
field in a message) bcz the descriptors section appears only afterwards.

What version of the product are you using? On what operating system?
-0.0

Please provide any additional information below.

What steps will reproduce the problem?
1. ./configure ./configure
CXXFLAGS=-I/home/ggne0279/hitendra/install/include
LDFLAGS=-L/home/ggne0279/hitendra/install/lib

2. make 
3.

What is the expected output? What do you see instead?
Successful  compilation

How ever make failed giving following errors

-------------------------------------------------------------------------

../protoc-c -I. --c_out=generated-code ./test.proto
mkdir -p generated-code
../protoc-c -I. --c_out=generated-code ./test-full.proto
mkdir -p generated-code
I. --cpp_out=generated-code ./test-full.proto
make[2]: I.: Command not found
make[2]: [generated-code/test-full.pb.h] Error 127 (ignored)
if g++ -DPACKAGE_NAME=\"protobuf-c\" -DPACKAGE_TARNAME=\"protobuf-c\"
-DPACKAGE_VERSION=\"0.11\" -DPACKAGE_STRING=\"protobuf-c\ 0.11\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"protobuf-c\" -DVERSION=\"0.11\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_SYS_POLL_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_ALLOCA_H=1
-DHAVE_MALLOC_H=1 -DPROTOC_VERSION=0 -DHAVE_ENDIAN_H=1 -DIS_LITTLE_ENDIAN=1
-I. -I. -I./..    -I/home/ggne0279/hitendra/install/include -MT
cxx-generate-packed-data.o -MD -MP -MF ".deps/cxx-generate-packed-data.Tpo"
-c -o cxx-generate-packed-data.o cxx-generate-packed-data.cc; \
then mv -f ".deps/cxx-generate-packed-data.Tpo"
".deps/cxx-generate-packed-data.Po"; else rm -f
".deps/cxx-generate-packed-data.Tpo"; exit 1; fi
cxx-generate-packed-data.cc:5:41: generated-code/test-full.pb.h: No such
file or directory
cxx-generate-packed-data.cc:9: error: expected namespace-name before ';' token
cxx-generate-packed-data.cc:9: error: `<type error>' is not a namespace
In file included from cxx-generate-packed-data.cc:16:
common-test-arrays.h:44: error: `TestEnumSmall' does not name a type
common-test-arrays.h:45: error: `TestEnumSmall' does not name a type
common-test-arrays.h:47: error: `TestEnumSmall' does not name a type
common-test-arrays.h:51: error: `TestEnum' does not name a type
common-test-arrays.h:52: error: `TestEnum' does not name a type
common-test-arrays.h:53: error: `TestEnum' does not name a type
cxx-generate-packed-data.cc:20: error: `google' has not been declared
cxx-generate-packed-data.cc:20: error: variable or field
`dump_message_bytes' declared void
cxx-generate-packed-data.cc:20: error: `Message' was not declared in this scope
cxx-generate-packed-data.cc:20: error: `message' was not declared in 

---------------------------------------------------

I saw the generated Makefile in the "protobuf-c-0.11/src/test" and the line
does not contain the command name which i think should be the protoc 

>>generated-code/test-full-cxx-output.inc: cxx-generate-packed-data$(EXEEXT)
    ./cxx-generate-packed-data > generated-code/test-full-cxx-output.inc

i then added the protoc myself to see if it compiles but it again produced
the folowing errors which are same as issue 20

cxx-generate-packed-data.cc: In function `void dump_test_unknown_fields()':
cxx-generate-packed-data.cc:767: error: no matching function for call to
`google::protobuf::UnknownFieldSet::Ad
dField(int)'
/home/ggne0279/hitendra/install/include/google/protobuf/unknown_field_set.h:108:
note: candidates are: void goo
gle::protobuf::UnknownFieldSet::AddField(const google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:768: error: 'class
google::protobuf::UnknownField' has no member named 'add_varint'
cxx-generate-packed-data.cc:769: error: no matching function for call to
`google::protobuf::UnknownFieldSet::Ad
dField(int)'
/home/ggne0279/hitendra/install/include/google/protobuf/unknown_field_set.h:108:
note: candidates are: void goo
gle::protobuf::UnknownFieldSet::AddField(const google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:770: error: 'class
google::protobuf::UnknownField' has no member named 'add_fixed32
'
cxx-generate-packed-data.cc:781: error: no matching function for call to
`google::protobuf::UnknownFieldSet::Ad
dField(int)'
/home/ggne0279/hitendra/install/include/google/protobuf/unknown_field_set.h:108:
note: candidates are: void goo
gle::protobuf::UnknownFieldSet::AddField(const google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:782: error: 'class
google::protobuf::UnknownField' has no member named 'add_length_
delimited'
cxx-generate-packed-data.cc:783: error: no matching function for call to
`google::protobuf::UnknownFieldSet::Ad
dField(int)'
/home/ggne0279/hitendra/install/include/google/protobuf/unknown_field_set.h:108:
note: candidates are: void goo
gle::protobuf::UnknownFieldSet::AddField(const google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:784: error: 'class
google::protobuf::UnknownField' has no member named 'add_fixed64
'


What version of the product are you using? On what operating system?
0.11 : OS= GNU/Red Hat linux  (2.6.9-22.ELsmp) 

Please provide any additional information below.

What steps will reproduce the problem?
1. Generate code via protoc-c using any valid proto file with an enum defined.

What is the expected output? What do you see instead?
Enums contain a comma after every entry.  Having a comma at the end of the
last value in the enum causes a pedantic warning.

What version of the product are you using? On what operating system?
0.2

Please provide any additional information below.

If you compile this with -j8 as a make flag (I'm on a Mac Pro), the sample 
program compiles before 
the library, causing a build error.

Forcing -j1 (one core, the default), the project compiles just fine.

Error output:


/usr/local/bin/protoc -I. --cpp_out=generated-code ./test-full.proto
cxx-generate-packed-data.cc:5:41: error: generated-code/test-full.pb.h: No such 
file or directory
cxx-generate-packed-data.cc:9: error: ‘foo’ is not a namespace-name
cxx-generate-packed-data.cc:9: error: expected namespace-name before ‘;’ 
token

What steps will reproduce the problem?
1. Make Visual Studio project and compile
2. Requires inttypes.h. Not part of Vis-C.
3.

What is the expected output? What do you see instead?
No compile errors.

What version of the product are you using? On what operating system?
0.13

Please provide any additional information below.
I included stdint.h and inttypes.h from  http://code.google.com/p/msinttypes/

In the latest release: protobuf-c-0.7:

in service_machgen_invoke() of protobuf-c.c:

I think:

  handlers = (GenericHandler *) machgen->service;

should be:

  handlers = (GenericHandler *) &machgen->service;

What steps will reproduce the problem?
Compile generated code with the following flags:

-g -Wunsafe-loop-optimizations  -Wunreachable-code -g -Wall -Wextra 
-Wlogical-op  -Wredundant-decls  -Wswitch-default -Wswitch-enum -Wshadow
-Wcast-align -Wwrite-strings -Wnested-externs  -Wdisabled-optimization
-Wstack-protector -O

What is the expected output? What do you see instead?
Compiler error: "ISO C does not allow extra ‘;’ outside of a function."

Each of the new init functions have a semicolon immediately after the
function's closing bracket.

What version of the product are you using? On what operating system?
protobuf-c 0.6, protobuf 2.0.1, Fedora 9/i686

Please provide any additional information below.

Thanks for the continued improvements to this project!

What steps will reproduce the problem?
Trying to build libprotobuf_c only in a cross-compilation setting for an
embedded target for which there is no interest in building the compiler. 

Would like to have a switch to configure script, e.g. --libonly, which then
doesn't check for availability of protobuf compiler etc.

What version of the product are you using? On what operating system?
libprotobuf-c-0.11 on Fedora core 10 host system. Target is OpenWRT which
runs on several embedded systems.

Please provide any additional information below.
A patch for configure, which solves the problem in a haphazardly way, is
attached. Not the correct solution I'm afraid. I'm not autoconf-proficient
enough to provide the correct solution...

What steps will reproduce the problem?
1. Download protobuf-2.2.0 and install `./configure && make && sudo make
install`
2. Download protobuf-c-0.11 and `./configure`
3. `make`

What is the expected output? What do you see instead?

Making all in src
 ...
Making all in .
if g++ -DPACKAGE_NAME=\"protobuf-c\" -DPACKAGE_TARNAME=\"protobuf-c\"
-DPACKAGE_VERSION=\"0.11\" -DPACKAGE_STRING=\"protobuf-c\ 0.11\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"protobuf-c\" -DVERSION=\"0.11\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_SYS_POLL_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_ALLOCA_H=1
-DPROTOC_VERSION=2002000 -DHAVE_MACHINE_ENDIAN_H=1 -DIS_LITTLE_ENDIAN=1 -I.
-I.     -g -O2 -MT c_enum_field.o -MD -MP -MF ".deps/c_enum_field.Tpo" -c
-o c_enum_field.o `test -f 'google/protobuf/compiler/c/c_enum_field.cc' ||
echo './'`google/protobuf/compiler/c/c_enum_field.cc; \
    then mv -f ".deps/c_enum_field.Tpo" ".deps/c_enum_field.Po"; else rm -f
".deps/c_enum_field.Tpo"; exit 1; fi
google/protobuf/compiler/c/c_enum_field.cc:26:45: error:
google/protobuf/wire_format_inl.h: No such file or directory
google/protobuf/compiler/c/c_enum_field.cc:33: error:
‘google::protobuf::internal::WireFormat’ has not been declared
make[2]: *** [c_enum_field.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

What version of the product are you using? On what operating system?
OSX 10.6.1 (Snow Leopard)

Please provide any additional information below.

Currently the only output we can see if unpack fails goes to stdout. Since
our program runs as a daemon, this is lost to us. How about a configurable
log handler (like the allocators) that this will call?

Someday we can want to support protobuf_c_parse_file().  We cannot implement 
the _init function, since it has no arguments that would indicate what type of 
message is being initialized.

Possibilities... protobuf_c_message_init() should be a proper function.  Or 
init() should take a descriptor object.

When a floating value or a 32-bit integer is decoded, the correct value will 
not be shown.


I am using protoc-c 2.0.3.

I changed the following functions to this in order to fix the problem:

For 32-bit ints:

static inline uint32_t
parse_uint32 (unsigned len, const uint8_t *data)
{
  uint32_t rv = data[0] & 0x7F;
  uint32_t tmp2;
  tmp2 = data[2] & 0x7f;
  tmp2 <<= 14;
  uint32_t tmp3;
  tmp3 = data[3] & 0x7f;
  tmp3 <<= 21;
  uint32_t tmp4;
  tmp4 = data[4] & 0x7f;
  tmp4 <<= 28;
  if (len > 1)
    {
      rv |= ((data[1] & 0x7f) << 7);
      if (len > 2)
        {

          //rv |= ((data[2] & 0x7f) << 14);
          rv |= tmp2;
          if (len > 3)
            {
              //rv |= ((data[3] & 0x7f) << 21);
              rv |= tmp3;
              if (len > 4)
                //rv |= ((data[4] & 0x7f) << 28);
                rv |= tmp4;
            }
        }
    }
  return rv;
}

And floats:
static inline uint32_t
parse_fixed_uint32 (const uint8_t *data)
{
#if IS_LITTLE_ENDIAN
  uint32_t t;
  memcpy (&t, data, 4);
  return t;
#else
  uint32_t ret;
  ret = data[3];
  ret <<= 8;
  ret |= data[2];
  ret <<= 8;
  ret |= data[1];
  ret <<= 8;
  ret |= data[0];
  //return data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24);
  return ret;
#endif
}


Could a preprocessor clause be put in to enable 16-bit mode?

Thank you in advance,
Greg Nehus

What steps will reproduce the problem?
1. install protobuf-2.1.0 (from ports) to FreeBSD 7-STABLE/amd64
2. run ./configure CXXFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
3. change alloca.h to stdlib.h (there is no alloca.h on FreeBSD)
4. re-run the above configure
5. run make, then crash

What is the expected output? What do you see instead?
I expected a normal configure-make run, but instead I get:
/bin/sh ../../libtool --tag=CXX --mode=link g++   -I/usr/local/include 
-L/usr/local/lib -o cxx-generate-packed-data  cxx-generate-packed-data.o
test-full.pb.o -lprotobuf
mkdir .libs
g++ -I/usr/local/include -o cxx-generate-packed-data
cxx-generate-packed-data.o test-full.pb.o  -L/usr/local/lib
/usr/local/lib/libprotobuf.so -lz   -Wl,--rpath -Wl,/usr/local/lib
-Wl,--rpath -Wl,/usr/local/lib
./cxx-generate-packed-data > generated-code/test-full-cxx-output.inc
Segmentation fault (core dumped)
*** Error code 139

Stop in /tmp/protobuf-c-0.11/src/test.
*** Error code 1

gdb says:
(gdb) bt
#0  0x000000080071b398 in std::_Rb_tree<std::string, std::pair<std::string
const, std::pair<void const*, int> >, std::_Select1st<std::pair<std::string
const, std::pair<void const*, int> > >, std::less<std::string>,
std::allocator<std::pair<std::string const, std::pair<void const*, int> > >
>::_M_insert_unique () from /usr/local/lib/libprotobuf.so.4
#1  0x000000080071b530 in
google::protobuf::InsertIfNotPresent<std::map<std::string, std::pair<void
const*, int>, std::less<std::string>, std::allocator<std::pair<std::string
const, std::pair<void const*, int> > > >, std::string, std::pair<void
const*, int> > () from /usr/local/lib/libprotobuf.so.4
#2  0x000000080071fc7d in
google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void
const*, int> >::AddFile () from /usr/local/lib/libprotobuf.so.4
#3  0x0000000800719e42 in google::protobuf::EncodedDescriptorDatabase::Add
() from /usr/local/lib/libprotobuf.so.4
#4  0x00000008006d151f in
google::protobuf::DescriptorPool::InternalAddGeneratedFile () from
/usr/local/lib/libprotobuf.so.4
#5  0x00000008007053fe in
google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto
() from /usr/local/lib/libprotobuf.so.4
#6  0x0000000800705c6f in __static_initialization_and_destruction_0 () from
/usr/local/lib/libprotobuf.so.4
#7  0x00000008007655c7 in __do_global_ctors_aux () from
/usr/local/lib/libprotobuf.so.4
#8  0x00000008006c5efe in _init () from /usr/local/lib/libprotobuf.so.4
#9  0x00007fffffffeb20 in ?? ()
#10 0x0000000800552415 in dlsym () from /libexec/ld-elf.so.1
#11 0x00000008005536c7 in dlopen () from /libexec/ld-elf.so.1
#12 0x000000080054e4c9 in ?? () from /libexec/ld-elf.so.1
#13 0x0000000000000000 in ?? ()
#14 0x0000000000000000 in ?? ()
#15 0x0000000000000000 in ?? ()

What version of the product are you using? On what operating system?
The latest, FreeBSD.


Please provide any additional information below.

What steps will reproduce the problem?
In Ubuntu 64 bit arch,
1. apt-get install libprotobuf3 libprotobuf-dev
2. Get the latest tar from here..
3. ./configure; make

What is the expected output? What do you see instead?
Successful compilation

What version of the product are you using? On what operating system?
Tested with protobuf-c-0.11 and protobuf-c-0.10

Please provide any additional information below.
Make log:
Making all in test
make[2]: Entering directory
`/home/pushkar/projects/mesa/protobuff_stuf/protobuf-c-0.10/src/test'
mkdir -p generated-code
../protoc-c -I. --c_out=generated-code ./test.proto
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
make[2]: *** [generated-code/test.pb-c.c] Aborted
make[2]: Leaving directory
`/home/pushkar/projects/mesa/protobuff_stuf/protobuf-c-0.10/src/test'
make[1]: *** [all-recursive] Error 1

This looks like a judgment call.

When I give a string member, but leave that string member NULL I get a
segmentation fault in required_field_get_packed_size(). I think seg
faulting is correct, but I figured I'd bring it up. 

    case PROTOBUF_C_TYPE_STRING:
      {
        size_t len = strlen (*(char * const *) member);
        return rv + uint32_size (len) + len;
      }

When the member is NULL, it blows up. 

What steps will reproduce the problem?
1. Install version 2.1.0 of the protobuf library
2. Compile version 0.10 of protobuf-c

What is the expected output? What do you see instead?

Expected: successful compilation.

Instead, you get an error message:

cxx-generate-packed-data.cc: In function ‘void dump_test_unknown_fields()’:
cxx-generate-packed-data.cc:761: error: no matching function for call to
‘google::protobuf::UnknownFieldSet::AddField(int)’
/opt/local/include/google/protobuf/unknown_field_set.h:108: note:
candidates are: void google::protobuf::UnknownFieldSet::AddField(const
google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:762: error: ‘class
google::protobuf::UnknownField’ has no member named ‘add_varint’
cxx-generate-packed-data.cc:763: error: no matching function for call to
‘google::protobuf::UnknownFieldSet::AddField(int)’
/opt/local/include/google/protobuf/unknown_field_set.h:108: note:
candidates are: void google::protobuf::UnknownFieldSet::AddField(const
google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:764: error: ‘class
google::protobuf::UnknownField’ has no member named ‘add_fixed32’
cxx-generate-packed-data.cc:768: error: no matching function for call to
‘google::protobuf::UnknownFieldSet::AddField(int)’
/opt/local/include/google/protobuf/unknown_field_set.h:108: note:
candidates are: void google::protobuf::UnknownFieldSet::AddField(const
google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:769: error: ‘class
google::protobuf::UnknownField’ has no member named ‘add_length_delimited’
cxx-generate-packed-data.cc:770: error: no matching function for call to
‘google::protobuf::UnknownFieldSet::AddField(int)’
/opt/local/include/google/protobuf/unknown_field_set.h:108: note:
candidates are: void google::protobuf::UnknownFieldSet::AddField(const
google::protobuf::UnknownField&)
cxx-generate-packed-data.cc:771: error: ‘class
google::protobuf::UnknownField’ has no member named ‘add_fixed64’


It looks like the UnknownField class's interface has changed.

What steps will reproduce the problem?
1. using src/test/test-generated-code.c, send person.phone[0]->number, but 
leave person.phone[0]->has_type untouched to simulate the behavior of 
optional field with a default
2. Dump person2->phone[0]->type, which shows up as 0

What is the expected output? What do you see instead?
We should see the default value specified in the proto file 
(FOO__PERSON__PHONE_TYPE__HOME), but this field shows up as 0 when has_type 
is 0. The C++ documentation describe the accessor as follows "Bar foo() 
const: Returns the current value of the field. If the field is not set, 
returns the default value"

What version of the product are you using? On what operating system?
0.5, Linux

Please provide any additional information below.

What steps will reproduce the problem?
1. generate a proto message taking default values
2. compile generated code with cygwin gcc on windows


What is the expected output? What do you see instead?
Case3.pb-c.c:365: error: `temperature__set__default_value' undeclared here 
(not in a function)
default value field has 

static const int32_t data_transporter__Set__default_value = 10; 
// upper case Set
static const ProtobufCFieldDescriptor 
data_transporter__field_descriptors[2] =
{
  {
   ...
    &data_transporter__set__default_value, // lower case set
    ...
  },
  ...
};

What version of the product are you using? On what operating system?
protobuf-c 0.6, protobuf 2.0.2, Windows Vista / cygwin

Please provide any additional information below.

in certain corner cases, e.g. an enum with three values, when
protobuf_c_enum_descriptor_get_value_by_name() is called to look up
a nonexistent name that comes after (in a strcmp() comparison) all 
the possible enum strings, the binary search will attempt to read
beyond the end of the enum_values_by_name array.

the attached patch appears to fix this.  ok to commit?

What steps will reproduce the problem?
1. downloaded protobuf-c-0.11 unziped and tared on solaris 
2. executed ./configure --prefix=/home/usr/install
3.

What is the expected output? What do you see instead?
configure should succeed 

-----------
checking google/protobuf/stubs/common.h usability... no
checking google/protobuf/stubs/common.h presence... no
checking for google/protobuf/stubs/common.h... no
configure: error:
ERROR: protobuf headers are required.

You must either install protobuf from google,
or if you have it installed in a custom location
you must add '-Iincludedir' to CXXFLAGS
and '-Llibdir' to LDFLAGS.

>> the configure says presence ofcommon.h is not required but it still says
it is an error. I saw the src/google/protobuf directory there is no dir
name stubs.



What version of the product are you using? On what operating system?
0.11

Please provide any additional information below.