2018-06-28 12:39 GMT+02:00 Matteo Bruni matteo.mystral@gmail.com:
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)
Oh *facepalm*, you're right. I didn't notice the opening and closing parentheses in the correct position.
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.
Maybe but still not very visible...
But this should answer the OPs question why it is done in this way.
Thanks for clarification, Kai