Paddding thing once more

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Paddding thing once more

Jakub Piotr Cłapa-2
Sorry for so many questions about boring things but I hope you excuse
three more.

1. The padding for every value is basically a constraint on it's start
address (counting from the beginning of the header or body) which must
be a multiple of the alignment value.

Example:
When we marshal "yyyu" then between "yyy" and "u" there must be one nul
byte (regardless of the endianess the padding is always before the value?)

2. The padding of header is simply adding some nul bytes to the end of
the header to make it's length divisible by 8? It has nothing to do with
header fileds (which are structs) 8-byte padding? (because their padding
always goes before the struct value not after it?)

3. Why? What is gained from using paddings in DBus protocol? (it's
probably a question about binary formats design theory) I found in the
source that this is borrowed from ORBit2 but haven't seen any
explanation why.

--
Regards,
Jakub Piotr Cłapa
--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus
Reply | Threaded
Open this post in threaded view
|

Re: Paddding thing once more

Havoc Pennington
On Mon, 2005-08-08 at 15:45 +0200, Jakub Piotr Cłapa wrote:

> Sorry for so many questions about boring things but I hope you excuse
> three more.
>
> 1. The padding for every value is basically a constraint on it's start
> address (counting from the beginning of the header or body) which must
> be a multiple of the alignment value.
>
> Example:
> When we marshal "yyyu" then between "yyy" and "u" there must be one nul
> byte (regardless of the endianess the padding is always before the value?)
>

Yes. I don't think endianness should matter here, afaik.

> 2. The padding of header is simply adding some nul bytes to the end of
> the header to make it's length divisible by 8? It has nothing to do with
> header fileds (which are structs) 8-byte padding? (because their padding
> always goes before the struct value not after it?)

Right.

> 3. Why? What is gained from using paddings in DBus protocol? (it's
> probably a question about binary formats design theory) I found in the
> source that this is borrowed from ORBit2 but haven't seen any
> explanation why.

The primary reason for the padding is that you can then use arrays and
structs in-place without copying them; just cast to a C type. This is
how dbus_message_iter_get_fixed_array() works. Some CPUs require the
data types to be aligned prior to access.

Havoc


--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus