Compiler Errors with CodeSourcery ARM GCC

[Brandon Schlinker]

I'm trying to compile a sample project containing some nanopb code using the CodeSourcery ARM GCC compiler. Please note that I'm compiling on Windows (sorry...)

I've properly compiled person.proto into person.pb.h/.c and have all of the other needed libraries (pb_de/encode.c/.h and pb.h). My main() has been lifted from the test_decode1.c file, and is as follows:

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

#include <stdio.h>

#include <pb_encode.h>

#include "Network/protocolBuffers/person.pb.h"

int main()

{

    /* Initialize the structure with constants */

    Person person = {"Test Person 99", 99, true, "te...@person.com",

        3, {{"555-12345678", true, Person_PhoneType_MOBILE},

            {"99-2342", false, 0},

            {"1234-5678", true, Person_PhoneType_WORK},

        }};

    uint8_t buffer[512];

    pb_ostream_t stream = pb_ostream_from_buffer(buffer, sizeof(buffer));

    /* Now encode it and check if we succeeded. */

    if (pb_encode(&stream, Person_fields, &person))

    {

        fwrite(buffer, 1, stream.bytes_written, stdout);

        return 0; /* Success */

    }

    else

    {

        return 1; /* Failure */

    }

}

--------

The compiler is unhappy with the initialization of the Person structure, as shown in the compiler errors below. Part of this was because my main was previously a .cpp instead of a .c, and I did not have ANSI support enabled (-ansi). This helped reduce some of the problems, but my compiler still complains that the structure is being initialized incorrectly:

../main.c: In function 'main':

../main.c:27:5: warning: missing braces around initializer [-Wmissing-braces]

../main.c:27:5: warning: (near initialization for 'person.name') [-Wmissing-braces]

../main.c:27:5: warning: initialization from incompatible pointer type [enabled by default]

../main.c:27:5: warning: (near initialization for 'person.name.funcs.decode') [enabled by default]

../main.c:27:5: warning: initialization makes pointer from integer without a cast [enabled by default]

../main.c:27:5: warning: (near initialization for 'person.name.arg') [enabled by default]

../main.c:27:5: warning: initialization from incompatible pointer type [enabled by default]

../main.c:27:5: warning: (near initialization for 'person.email.funcs.decode') [enabled by default]

../main.c:28:9: warning: initialization makes pointer from integer without a cast [enabled by default]

../main.c:28:9: warning: (near initialization for 'person.email.arg') [enabled by default]

../main.c:28:9: warning: initialization from incompatible pointer type [enabled by default]

../main.c:28:9: warning: (near initialization for 'person.phone.funcs.decode') [enabled by default]

../main.c:28:9: warning: excess elements in union initializer [enabled by default]

../main.c:28:9: warning: (near initialization for 'person.phone.funcs') [enabled by default]

../main.c:28:9: warning: excess elements in union initializer [enabled by default]

../main.c:28:9: warning: (near initialization for 'person.phone.funcs') [enabled by default]

../main.c:29:13: warning: braces around scalar initializer [enabled by default]

../main.c:29:13: warning: (near initialization for 'person.phone.arg') [enabled by default]

../main.c:29:13: warning: excess elements in scalar initializer [enabled by default]

../main.c:29:13: warning: (near initialization for 'person.phone.arg') [enabled by default]

../main.c:29:13: warning: excess elements in scalar initializer [enabled by default]

../main.c:29:13: warning: (near initialization for 'person.phone.arg') [enabled by default]

../main.c:30:13: error: extra brace group at end of initializer

../main.c:30:13: error: (near initialization for 'person.phone')

../main.c:30:13: warning: excess elements in struct initializer [enabled by default]

../main.c:30:13: warning: (near initialization for 'person.phone') [enabled by default]

cs-make: *** [main.o] Error 1

Any help would be appreciated!

Thanks,

Brandon

[petteri...@gmail.com]

Hi,

> I've properly compiled person.proto into person.pb.h/.c and have all of the
> other needed libraries (pb_de/encode.c/.h and pb.h).

Just to verify that nothing strange has happened, this is what Person
structure looks for me in person.pb.h:

typedef struct _Person {
char name[40];
int32_t id;
bool has_email;
char email[40];
size_t phone_count;
Person_PhoneNumber phone[5];
} Person;

> My main() has been lifted from the test_decode1.c file, and is as follows:

Hmm, I tried a simple test using CodeSourcery 2011.09 on Linux:

arm-none-eabi-gcc -Wall -I .. -c test_encode1.c

Compiles without errors. What happens if you try that file?

> ../main.c:27:5: warning: missing braces around initializer

> ../main.c:27:5: warning: (near initialization for 'person.name')

> ../main.c:27:5: warning: initialization from incompatible pointer type

It seems that somehow your strings are not char arrays. Is it possible
that you have some strange unicode support on?

I haven't had any problems with CodeSourcery with default settings,
though.

--
Petteri

[Brandon Schlinker]

First -- thanks for the quick response -- I really appreciate it.

It looks like there is an issue on my side in compiling the person.proto files into the person.pb.h/c files.

Here is the start of my person.pb.h file -- I noticed that the structure for the person does not match yours -- for instance it contains "pb_callback_t" as the type for the name field. I wasn't aware that this was unexpected behavior until now.

/* Automatically generated nanopb header */

#ifndef _PB_PERSON_PB_H_

#define _PB_PERSON_PB_H_

#include <pb.h>

/* Enum definitions */

typedef enum {

    Person_PhoneType_MOBILE = 0,

    Person_PhoneType_HOME = 1,

    Person_PhoneType_WORK = 2

} Person_PhoneType;

/* Struct definitions */

typedef struct {

    pb_callback_t name;

    int32_t id;

    pb_callback_t email;

    pb_callback_t phone;

} Person;

typedef struct {

    pb_callback_t number;

    bool has_type;

    Person_PhoneType type;

} Person_PhoneNumber;

Here is how I compile person.proto....

C:\bulbOS\Network\protocolBuffers>python\protocolBuffers>protoc -operson.pb person.proto

C:\bulbOS\Network\protocolBuffers>python ../../Libraries/nanoPB/generator/nanopb_generator.py person.pb"

Writing to person.pb.h and person.pb.c

The protoc binary which I am using is straight from Google -- I've added it to my PATH. nanopb files are all v0.16, although I'll try v0.17-beta in a moment. descriptor.proto is straight out of Google's .zip of the protocol buffer components -- I extracted it to a relative directory, as Python doesn't seem to recognize that I added it to my PATH.

Any ideas on the unexpected behavior here?

Thanks,

Brandon

[petteri...@gmail.com]

Hi,

> Here is the start of my person.pb.h file -- I noticed that the structure
> for the person does not match yours -- for instance it contains
> "pb_callback_t" as the type for the name field.

Perhaps your person.proto doesn't contain the nanopb max size
definitions? To allocate static string members, nanopb has to know the
maximum size used for the field. Otherwise it generates callback
entries.

See for example
https://code.google.com/p/nanopb/source/browse/tests/person.proto
http://koti.kapsi.fi/~jpa/nanopb/docs/concepts.html#compiling-proto-files-with-nanopb-options

> The protoc binary which I am using is straight from Google -- I've added it
> to my PATH. nanopb files are all v0.16, although I'll try v0.17-beta in a
> moment.

With 0.17 you don't necessarily have to specify the size in the .proto,
you can also give -s max_size:40 to the nanopb_generator.py.

--
Petteri

[Brandon Schlinker]

Yep -- that looks like the issue. I had been under the impression that setting the maximum size for the field was not required -- but given the static allocation properties of nanopb, it makes perfect sense that it is. I'm guessing the callbacks which are generated are for the dynamic allocation work, which is mentioned as future work in the wiki?

I had actually forgotten that I had removed those lines -- I added them back in and it compiled to match what you had shown previously.

That said, it is nice that 0.17 does not require these entries directly within the .proto, as I will be utilizing the .proto files with a PHP protocol buffer library, and this may enable me to just have one standard of the .protos instead of a special copy for nanopb. Of course, this requires a common maximum size for all fields, which is potentially wasteful -- I'll have to evaluate the impact on my side.

Thanks,

Brandon

[petteri...@gmail.com]

Hi,

> I'm guessing the callbacks which are generated are for the dynamic
> allocation work, which is mentioned as future work in the wiki?

Actually no.

Callbacks are already usable, and they simply call a function you
specify. In that function you can do whatever you want, like allocating
storage or directly writing the data to a file. This is quite useful for
handling large messages with limited memory resources.

http://koti.kapsi.fi/~jpa/nanopb/docs/concepts.html#field-callbacks

> Of course, this requires a common maximum size for all fields, which
> is potentially wasteful -- I'll have to evaluate the impact on my
> side.

Yeah. Eventually there should be a way to define per-field properties in
a separate file, but I haven't implemented it yet.

--
Petteri