[Xcb] [PATCH libxcb 3/3] generator: optionally enable/disable implicit_padding

[Peter Harris]

On 2014-08-21 16:35, Christian Linhart wrote:
> This is controlled by the new ComplexType-member "implicit_padding"
> which is set by the parser.
> (See corresponding patch for the parser for xcb/proto)
> 
> The first change:
> For inserting the padding before or after var-size fields
> it adds the condition that implicit_padding must be true.
> 
> The second change:
> Compute align_to only when implicit_padding is enabled

I was studying the results of this change, and it turns out that the
implicit padding inserted by the generator is actually a no-op since
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=aa02096b8e7f94ad3c998a8d5af54963ee860b13
changed xcb_align_to to be the alignment of the previous field.

The previous field was already naturally aligned[2], therefore the
current position must already be aligned to the alignment of the
previous field.

I suspect we only need the xcb_align_to variable iff
self.contains_explicit_alignpads.

If we stop generating the noop[1] implicit padding between lists, is the
implicit-padding=false tag still necessary, or is there another issue
that I missed seeing?

Thanks,
 Peter Harris

[1] In my test branch, I dropped implicit padding and reviewed some of
the generated code. I didn't manage to find a case where it made any
difference. I also didn't manage to stay awake long enough to review the
entire delta. If there is a case where implicit padding is necessary,
let's change it to explicit padding now that we have <pad align> and
drop implicitly padded lists anyway.
[2] By definition. If it wasn't naturally aligned, it was already broken.
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866