Discrepancy of max_size between string and bytes types

[GoogleCodeExporter]

Suppose I have the following:

foo.proto:

message Foo {
    required bytes b = 1;
    required string s = 2;
}

foo.options:

Foo.b max_size:10
Foo.s max_size:10

Nanopb will generate the following:

typedef struct {
    size_t size;
    uint8_t bytes[10];
} Foo_b_t;

typedef struct _Foo {
    Foo_b_t b;
    char s[10];
} Foo;

While this might seem fine for a C programmer, it doesn't feel logical for a 
protocol designer. The issue is that one is able to store 10 bytes of data in 
"b", but only 9 characters in "s" (because of the zero-terminated string). 

My suggestion would be to generate

    char s[10+1];

for the mentioned case, so even the string can hold 10 characters.

I think the suggestion follows the least surprise principle. 

Original issue reported on code.google.com by rusn...@gmail.com on 2 Mar 2014 at 5:19

[GoogleCodeExporter]

It's a valid point. On the other hand, if one wants to do something like:

Foo.* max_size:16

it makes more sense to have the C size be 16 bytes, so that fields stay nicely 
aligned and no space is lost to padding. Saying max_size:16 and having 20 bytes 
allocated for each field is not very logical either.

I'm not so sure which way is better. I'll leave this issue as "Tentative" for 
now, and if anyone has new arguments in either direction, please add a comment.

Original comment by Petteri.Aimonen on 2 Mar 2014 at 5:28

• Changed state: Tentative
• Added labels: Type-Review, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Doing the +1 seems reasonable and will be implemented in nanopb-0.3.0.

Original comment by Petteri.Aimonen on 4 Aug 2014 at 4:25

• Changed state: Accepted

[GoogleCodeExporter]

Oops, forgot to tag it => forgot to do it.
Oh well, it can wait.

Original comment by Petteri.Aimonen on 27 Aug 2014 at 12:23

• Added labels: Milestone-0.4