From [email protected] on December 08, 2008 12:14:00

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!

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=10

From [email protected] on November 11, 2009 09:57:44

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=30

From [email protected] on June 01, 2009 08:56:32

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

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

Attachment: issue-21.patch

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=21

From [email protected] on August 27, 2008 10:10:30

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=5

From [email protected] on December 04, 2009 12:47:59

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=31

From [email protected] on July 05, 2010 08:57:20

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=43

From [email protected] on September 15, 2010 07:42:53

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=49

From [email protected] on February 08, 2010 17:30:42

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?

Attachment: 0001-protobuf-c.c-fix-protobuf_c_enum_descriptor_get_valu.patch

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=35

From [email protected] on August 25, 2008 06:45:03

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.

Attachment: pbcissue3.zip

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=3

From [email protected] on May 25, 2009 11:26:09

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=19

From [email protected] on September 09, 2008 15:21:33

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

Thanks!

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=8

From dcreager on May 30, 2009 15:39:14

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=20

From ivaxer on November 09, 2009 09:40:12

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=28

From [email protected] on April 15, 2010 01:29:59

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=40

From [email protected] on March 25, 2010 16:13:17

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=38

From [email protected] on December 27, 2009 16:54:43

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.

Attachment: protobuf-c-service-segfault-fix.patch

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=32

From [email protected] on August 27, 2008 10:04:35

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=4

From [email protected] on December 12, 2008 10:13:22

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=11

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=14

From [email protected] on September 08, 2008 17:14:55

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=7

From [email protected] on August 07, 2010 21:20:24

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=44

From [email protected] on August 25, 2008 04:58:39

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=2

From [email protected] on June 24, 2009 07:33:07

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::lessstd::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::lessstd::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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=22

From [email protected] on July 07, 2009 02:20:31

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

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=24

From [email protected] on September 16, 2010 07:59:18

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?

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=50

From [email protected] on January 25, 2009 23:13:33

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=13

From [email protected] on October 15, 2009 19:11:19

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?

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=26

From [email protected] on May 14, 2009 05:01:15

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=18

From [email protected] on March 06, 2009 16:12:13

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/Dependencies/protobuf-2.0.3/src/protobuf-c.c http://code.google.com/p/plcrashreporter/source/detail?r=263&path=/trunk/Dependencies/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

Attachment: protobuf-fuz.tar.gz

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=16

From [email protected] on January 07, 2010 12:39:00

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

Attachment: protobuf_libonly.patch

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=34

From [email protected] on April 09, 2009 08:00:21

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=17

From [email protected] on September 09, 2010 23:25:16

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=48

From [email protected] on March 15, 2010 16:31:18

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=36

From [email protected] on January 05, 2010 14:13:38

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=33

From [email protected] on August 25, 2008 01:58:28

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
3. build What is the expected output? What do you see instead? 1. compile of generated code fails
4. make fails What version of the product are you using? On what operating system? -0.0 Please provide any additional information below. Redhat, Linux

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=1

From [email protected] on September 08, 2008 11:29:36

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=6

From [email protected] on August 26, 2010 10:58:05

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=47

From [email protected] on July 01, 2009 04:25:00

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=23

From [email protected] on September 17, 2009 15:19:18

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=25

From [email protected] on August 21, 2010 10:26:40

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

Attachment: check_required_fields_have_been_set.diff

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=46

From [email protected] on August 08, 2010 00:21:19

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=45

From [email protected] on February 17, 2009 14:05:24

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.

Attachment: protobuf-c-alloc-fail.patch

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=15

From [email protected] on April 14, 2010 22:52:45

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=39

From [email protected] on November 10, 2009 18:58:39

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.

Attachment: required_field_pack_big_endian_fix.diff

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=29

From [email protected] on March 16, 2010 19:17:34

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=37

From [email protected] on January 17, 2009 11:10:09

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;

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=12

From [email protected] on June 09, 2010 06:41:50

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=42

From [email protected] on October 09, 2008 16:19:38

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.

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=9

From [email protected] on November 07, 2009 11:41:58

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

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=27

From [email protected] on June 09, 2010 05:19:07

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/

Original issue: http://code.google.com/p/protobuf-c/issues/detail?id=41