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

[Kai Krakow]

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. This is exploiting implicit
behavior which is almost always a bad thing to do if you need to
understand code later.

Regards,
Kai