Dict parsing question

[Simon McVittie]

On Tue, 02 Jan 2024 at 11:47:30 +0000, Simon McVittie wrote:
> For example, a message body with
> signature 'uat' and value "uint32 0xaaaaaaaa, [uint64 0xbbbbbbbbcccccccc]"
> (shown below in big-endian) fits neatly into the minimal 16 bytes required

Perhaps I didn't make it clear enough, but when I said "a message body"
here, I meant to imply that the "cursor" is at a multiple of 8 bytes
when serialization begins. This is true because the D-Bus Specification
requires it to be true:

     The length of the header must be a multiple of 8, allowing the body
     to begin on an 8-byte boundary when storing the entire message in
     a single buffer. If the header does not naturally end on an 8-byte
     boundary up to 7 bytes of nul-initialized alignment padding must
     be added.

(When choosing alignments, all offsets are measured starting from the
beginning of the message, which is the beginning of the header.)

Because in this example I serialized a uint32 first, and then the
array, the result is that the array is at the (8 * n) + 4 position that
Lawrence's replies allude to:

     |8n         |8n+4
     v           v
>     aa aa aa aa                # uint32 0xaaaaaaaa                   } u
>                                # no padding needed for array length
>                 00 00 00 08    # array length = 0x8 bytes            }
>                                # no padding needed for type t        } at
>     bb bb bb bb cc cc cc cc    # first element = 0xbbbbbbbbcccccccc  }

and you'll see that the serialization of the array in this case was 12
bytes, { 00 00 00 08  bb bb bb bb  cc cc cc cc }.

> For example, consider a message body
> with signature 'at' and value "[uint64 0xbbbbbbbbcccccccc]"

Similarly, in this case the position of the "cursor" before starting to
serialize the array is 8*n for some n:

     |8n         |8n+4
     v           v
>     00 00 00 08                # array length = 0x8 bytes
>                 00 00 00 00    # padding to 8-byte alignment of type t
>     bb bb bb bb cc cc cc cc    # first element = 0xbbbbbbbbcccccccc

and as Lawrence points out in another reply, this time the exact same
array was serialized as 16 bytes rather than 12, with 4 bytes of
zero-padding between the array length and the elements.

This offset-dependent serialization of the same content is not ideal, but
it's the price we pay for having all of the elements be naturally-aligned.

    smcv