in pms_proc_mouse, wsmouse_input is called with an uninitialized
'dz' variable if the sc->protocol->type is not PMS_STANDARD or
PMS_INTELLI.
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.43
diff -u -p
We experienced a "quirk" with persistence and multiple listen addresses on
redirects, such as listening to both port 21 and a passive port range for load
balancing FTP, because the session's stickiness seems to operate per-pass-rule.
One solution would be group all rules as matches under one pas
Hi,
So far i got no comments if this fix is ok or not.
Is there any better way to do the comparison without just casting the values to
int8_t?
Greetings,
Matthias
On Fri, Jun 28, 2013 at 09:11:13AM +0200, Janne Johansson wrote:
> Now the hard part is to figure out exactly where it should have been
> initialized and to what. Just setting it to 0 somewhere is not necessarily
> better.
It seems the mips64/mips64/cache_tfp.c one is a proper bug. Looking at the
c
Now the hard part is to figure out exactly where it should have been
initialized and to what. Just setting it to 0 somewhere is not necessarily
better.
2013/6/28 Maxime Villard
> Hi,
> some other uninitialized vars found by my scanner in arch/.
>
> == hp300/dev/hd.c
> At l.544, 'error' is
Hi,
some other uninitialized vars found by my scanner in arch/.
== hp300/dev/hd.c
At l.544, 'error' is not initialized.
== luna88k/luna88k/autoconf.c
At l.132, 'c' may be uninitialized.
== mips64/mips64/cache_tfp.c
At l.109, 'eva' is not initialized.
== sparc/dev/zs.c
At l.513, 'tm
