On 8/05/2014 16:57 , Samuel Thibault wrote:
Peter Hutterer, le Thu 08 May 2014 13:01:03 +1000, a écrit :
This way if the ioctl fails we don't set any unintended LEDs, but really this
patch is more to silence valgrind:
==7129== Conditional jump or move depends on uninitialised value(s)
==7129== at 0x8DF99A1: GetKbdLeds (lnx_kbd.c:79)
==7129== by 0x8DF8853: InitKBD (kbd.c:291)
Err, I would rather say that this is a sign that GetKbdLeds should check
the value returned by ioctl it case it fails, and handle that case,
instead of clearing LEDs?
Or at least a warning should be put, so the user can know something is
weird and precisely where, instead of letting him wondering why the LEDs
are cleared.
Yeah, we could put a warning in, but tbh since this is the
linux-specific code it's rather academic. evdev has well and truly
superseded the keyboard driver on linux, so at this point I consider any
work on it superfluous (minus compiler warnings, valgrind errors that
trip up my test scripts :)
Cheers,
Peter
Signed-off-by: Peter Hutterer <[email protected]>
---
src/lnx_kbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lnx_kbd.c b/src/lnx_kbd.c
index e69e1b6..811a7d7 100644
--- a/src/lnx_kbd.c
+++ b/src/lnx_kbd.c
@@ -70,7 +70,7 @@ SetKbdLeds(InputInfoPtr pInfo, int leds)
static int
GetKbdLeds(InputInfoPtr pInfo)
{
- char real_leds;
+ char real_leds = 0;
int leds = 0;
ioctl(pInfo->fd, KDGETLED, &real_leds);
--
1.9.0
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
