[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