On 03/13/2013 07:18 PM, mdroth wrote:
On Wed, Mar 13, 2013 at 06:00:24PM -0400, Stefan Berger wrote:
On 03/13/2013 04:52 PM, mdroth wrote:
Visitors don't have any knowledge of the data structures they're visiting
outside of what we tell them via the visit_*() API.
[...]
For example, a visitor for a 16-element array of:
typedef struct ComplexType {
int32_t foo;
char *bar;
} ComplexType;
would look something like:
visit_start_carray(v, ...); // instruct visitor how to calculate offsets
for (i = 0; i < 16; i++) {
visit_type_ComplexType(v, ...) // instruct visitor how to handle elem
visit_next_carray(v, ...); // instruct visitor to move to next offset
}
visit_end_carray(v, ...); // instruct visitor to finalize array
Given this example above, I think we will need the sized buffer. The
sized buffer targets binary arrays and their encoding. If I was to
encode an 'unsigned char[n]' (e.g., n=200) using n, or n/2 or n/4
loops like above breaking it apart in u8, u16 or u32 respectively I
think this would 'not bed good' also considering the 2 bytes for tag
and length being added by ASN.1 for every such datatype
(u8,u16,u32). The sized buffer allows you to for example take a
memory page and write it out in one chunk adding a few bytes of
ASN.1 'decoration' around the actual data.