[Xcb] remove implicit padding code generally? ( was: [PATCH proto 2/2] xinput: rep QueryDeviceState struct InputState: full support )
Christian Linhart
chris at DemoRecorder.com
Thu Aug 28 08:55:15 PDT 2014
On 08/28/14 17:04, Peter Harris wrote:
> I prefer explicit padding only.
Me, too.
> If there is general consensus that we are going to remove implicitly
> generated padding code, I'll spend the day or two necessary to review
> the diff of the generated code.
Thank you very much for offering to do that work.
>From my reviews of "xinput" and "xkb" I can already say that they are
safe once I'll have posted fixes for all issues which I have found.
So, you need not review "xinput" and "xkb".
( I will post my xkb-patches some a few weeks after we are finished with
the xinput stuff. )
>
> There are many diff hunks, but review goes quickly because all (or at
> least most; I haven't seen a counter-example yet) of them are obviously
> noop.
As soon as we have general consensus to remove implicitly generated padding code,
I'll rework my patch to disable implicit padding completely
instead of optionally.
I'll post the resulting patch in a new thread then,
because it'll be rather independent of QueryDeviceState stuff.
>
>> solution 2:
>> derive the padding-offset from the pointer which is passed
>> to functions like serialize, unpack, sizeof.
>
> This makes more sense to me than solution 1.
Thank you.
I'll add a patch to this thread which fixes the padding of switch
which starts at an unaligned position.
>
>> ***
>>
>> Which alternative of
>> * generally disabling implicit-padding
>> * or fixing the switch-alignment
>> should we choose?
>>
>> Or should we choose both alternatives?
>
> I suspect that we'll need both alternatives, since an accurate offset
> will be needed for any <pad align> tokens that appear within a <case>.
This was my guess, too.
Chris
More information about the Xcb
mailing list