Option to discard excess repeated/string beyond max_size/count

[GoogleCodeExporter]

Describe the requested feature:

Allow an option (via a #define perhaps) for repeated fields that exceed a 
specified max_count, and strings that exceed max_size during decode() to be 
truncated. For example, if the option was enabled, any repeated fields in 
excess of the declared max_count would simply be ignored, rather than causing a 
decode failure, and any strings longer than the declared max_size would be 
truncated to fit (the excess bytes on the wire would be discarded)

In what situation would the feature be useful:

Given the example implementation where one system is using nanobp, and another 
system is using Java (or another language where the String type/class used by 
the protocol buffer is only available as a dynamically sized object), having to 
check that the size of a string/array doesn't exceed the declared nanopb 
max_??? option can be quite tedious. For instance, checking a field option for 
an extension in the Java implementation of protocol buffers involves jumping 
through a few hoops. It's possible to declare all of the sizes as constants 
somewhere in the Java source, but this creates two places where the 
max_count/size information must be maintained then.

I attached an example of what I'm using as a workaround at the moment. It's not 
pretty, but it gets the job done.

Original issue reported on code.google.com by tullisar on 31 Jan 2014 at 1:08

Attachments:

• example.c

[GoogleCodeExporter]

I'm a bit wary about truncating data. Generally, truncated data is pretty much 
incorrect data.

Is there a specific reason why truncating would be ok in your case?

Providing an option for this would be possible, but I'm not yet convinced that 
this is widely enough useful. One thing that might make sense is to allow 
optional fields to be skipped if the data does not fit.

Original comment by Petteri.Aimonen on 1 Feb 2014 at 7:09

• Changed state: Tentative
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I agree that truncating bytes fields would not make too much sense. In some 
cases however, a string could be truncated if it's a short message that might 
occasionally exceed the defined max_size field if one system isn't fully aware 
of the max_size restriction. 

Provided repeated fields are packed, they might be used to indicate the result 
of a data query. If the system not using nanopb didn't keep track of the 
max_count information, it could often respond with too much data for the 
max_count field.

Neither situation is that common, I'll admit. Though they would be useful in a 
few cases in the system with which I'm working. Another thought is perhaps a 
separate field option (max_size_trunc / max_count_trunc or some such), but that 
seems like even more work than preprocessor macros. 

Original comment by tullisar on 2 Feb 2014 at 5:36

[GoogleCodeExporter]

Too rare usecase. Better handled using callbacks or custom patch.

Original comment by Petteri.Aimonen on 2 Apr 2014 at 6:26

• Changed state: WontFix