[PATCH 1/4] xkb: LockMods can lock another group on key release #865

[Peter Hutterer]

On Wed, Jan 09, 2013 at 09:19:25PM +0100, wettstein509 at solnet.ch wrote:
> > * where are the bytes guaranteed to be zero? Not questioning, I just want to
> >   double-check and it's outside the patch contexts
> 
> I looked into xkbcomp source.  Before the actions structs are written to
> according to the specification in the .xkb file, they are indeed zeroed.
> For specifications in xkb_symbols (symbols.c), this is done by a call to
> uTypedRecalloc in function ResizeKeyGroup.  For specifications in
> xkb_compatibility (compat.c), it is done by an explicit loop in function
> InitCompatInfo.

ok. unfortunately, source isn't quite enough here, unless the protocol
explicitly specifies the bytes must be zero we cannot rely on this.

> > So really, the only danger we have here is potentially breaking clients that
> > expect XkbModAction to be 6 bytes, because of whatever reason. The safest
> > approach would be to add a new struct here (XkbModAction2) and use that
> > everywhere to avoid this issue. Daniel, any opinion?
> 
> Good point, I never thought about this.  I did a quick check in the X
> code that comes with NetBSD and it did not turn up any problem, but that
> does not mean much, of course.
> 
> I would have thought even less about the stuff that Daniel brought up.
> I am quite impressed that such a simple change can be so difficult if it
> is done right.

yeah, extensions have that tendency. we'll also need plenty of test cases to
make sure we don't screw this up anywhere, ideally with 1.0 and 1.1 protocol
testing etc.

on the positive side, from the user's POV it'll be mostly transparent - if
libX11 is new enough, it'll just work.

Cheers,
   Peter