2018-06-28 9:05 GMT+02:00 Kai Krakow kai@kaishome.de:
Hello again!
2018-06-28 8:56 GMT+02:00 Kai Krakow kai@kaishome.de:
Hello!
2018-06-27 21:14 GMT+02:00 Alex Henrie alexhenrie24@gmail.com:
On Wed, Jun 27, 2018 at 11:24 AM John Found johnfound@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.