Bug #45385 related to keyboard and probably wineserver - where to start the search

[Matteo Bruni]

2018-06-28 9:05 GMT+02:00 Kai Krakow <kai at kaishome.de>:
> Hello again!
>
> 2018-06-28 8:56 GMT+02:00 Kai Krakow <kai at kaishome.de>:
>> Hello!
>>
>> 2018-06-27 21:14 GMT+02:00 Alex Henrie <alexhenrie24 at gmail.com>:
>>> On Wed, Jun 27, 2018 at 11:24 AM John Found <johnfound at asm32.info> wrote:
>>>>
>>>> While reading the code in wineX11.drv/keyboard.c I noticed the following fragment from the function X11DRV_KeymapNotify:
>>>>
>>>>     for (vkey = VK_LSHIFT; vkey <= VK_RMENU; vkey++)
>>>>     {
>>>>         int m = vkey - VK_LSHIFT;
>>>> >>>     if (modifiers[m].vkey && !(keystate[vkey] & 0x80) != !modifiers[m].pressed)
>>>>         {
>>>>             TRACE( "Adjusting state for vkey %#.2x. State before %#.2x\n",
>>>>                    modifiers[m].vkey, keystate[vkey]);
>>>>
>>>>             update_key_state( keystate, vkey, modifiers[m].pressed );
>>>>             changed = TRUE;
>>>>         }
>>>>     }
>>>>
>>>> Can someone explain what the condition pointed by >>> is doing? (Unfortunately, my C skills are pretty low...)
>>>>
>>>> Why not simply "(modifiers[m].vkey && (keystate[vkey] & 0x80) != modifiers[m].pressed)"?
>>>
>>> I don't immediately know what this if statement is for, but I can tell
>>> you that the ! operator converts a value of zero to 1 and a nonzero
>>> value to 0. So, if keystate[vkey] & 0x80 is 0 then
>>> modifiers[m].pressed must be nonzero and vice versa.
>>
>> I always was under the impression that the bang operator does a binary
>> inversion of the value. Thus, it would convert 0x7F to 0x80. This also
>> means it would convert 0x00 (signed) to 0xFF (signed) which turns 0
>> into -1, not 1.
>>
>> But however it works, this code is not working in any obvious way and
>> should maybe be rewritten.
>>
>> Just my two cents.
>
> I just looked it up, the bang operator seems to be a logical (not
> binary) operator in C99:
> https://stackoverflow.com/questions/3661751/what-is-0-in-c
>
> According to this, I question how the code above is supposed to work
> in the first place because "!modifiers[m].pressed" would always be 0
> or 1, and it is compared to 0 or 0x80.

No, it's compared to 0 or 1 (there is a ! on the left hand side of the == too)

> This is exploiting implicit
> behavior which is almost always a bad thing to do if you need to
> understand code later.

It's pretty clear and explicit I'd say.