Note about __BIG_ENDIAN__ compilation option
[apps/agl-service-can-low-level.git] / docs / concepts.rst
index fac9061..1d0fe08 100644 (file)
@@ -4,7 +4,7 @@ Nanopb: Basic concepts
 
 .. include :: menu.rst
 
-The things outlined here are common to both the encoder and the decoder part.
+The things outlined here are the underlying concepts of the nanopb design.
 
 .. contents::
 
@@ -158,7 +158,10 @@ required bytes data = 1 [(nanopb).max_size = 40];
                                                                                 | Person_data_t data;
 =============================================================================== =======================
 
-The maximum lengths are checked in runtime. If string/bytes/array exceeds the allocated length, *pb_decode* will return false. 
+The maximum lengths are checked in runtime. If string/bytes/array exceeds the allocated length, *pb_decode* will return false.
+
+Note: for the *bytes* datatype, the field length checking may not be exact.
+The compiler may add some padding to the *pb_bytes_t* structure, and the nanopb runtime doesn't know how much of the structure size is padding. Therefore it uses the whole length of the structure for storing data, which is not very smart but shouldn't cause problems. In practise, this means that if you specify *(nanopb).max_size=5* on a *bytes* field, you may be able to store 6 bytes there. For the *string* field type, the length limit is exact.
 
 Field callbacks
 ===============
@@ -176,9 +179,13 @@ Encoding callbacks
 
 When encoding, the callback should write out complete fields, including the wire type and field number tag. It can write as many or as few fields as it likes. For example, if you want to write out an array as *repeated* field, you should do it all in a single call.
 
-If the callback is used in a submessage, it will be called multiple times during a single call to `pb_encode`_. It must produce the same amount of data every time. If the callback is directly in the main message, it is called only once.
+Usually you can use `pb_encode_tag_for_field`_ to encode the wire type and tag number of the field. However, if you want to encode a repeated field as a packed array, you must call `pb_encode_tag`_ instead to specify a wire type of *PB_WT_STRING*.
+
+If the callback is used in a submessage, it will be called multiple times during a single call to `pb_encode`_. In this case, it must produce the same amount of data every time. If the callback is directly in the main message, it is called only once.
 
 .. _`pb_encode`: reference.html#pb-encode
+.. _`pb_encode_tag_for_field`: reference.html#pb-encode-tag-for-field
+.. _`pb_encode_tag`: reference.html#pb-encode-tag
 
 This callback writes out a dynamically sized string::
 
@@ -197,7 +204,7 @@ Decoding callbacks
 
     bool (*decode)(pb_istream_t *stream, const pb_field_t *field, void *arg);
 
-When decoding, the callback receives a length-limited substring that reads the contents of a single field. The field tag has already been read.
+When decoding, the callback receives a length-limited substring that reads the contents of a single field. The field tag has already been read. For *string* and *bytes*, the length value has already been parsed, and is available at *stream->bytes_left*.
 
 The callback will be called multiple times for repeated fields. For packed fields, you can either read multiple values until the stream ends, or leave it to `pb_decode`_ to call your function over and over until all values have been read.
 
@@ -207,7 +214,7 @@ This callback reads multiple integers and prints them::
 
     bool read_ints(pb_istream_t *stream, const pb_field_t *field, void *arg)
     {
-        while (stream.bytes_left)
+        while (stream->bytes_left)
         {
             uint64_t value;
             if (!pb_decode_varint(stream, &value))