Subject: Re: CVS commit: src/sys/dev/wscons
To: Christos Zoulas <email@example.com>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
Date: 02/10/2006 20:13:05
On Friday 10 February 2006 19:31, Christos Zoulas wrote:
> On Feb 10, 6:41pm, email@example.com ("Julio M. Merino Vidal") wrote:
> -- Subject: Re: CVS commit: src/sys/dev/wscons
> | On Friday 10 February 2006 18:33, Christos Zoulas wrote:
> | > Module Name: src
> | > Committed By: christos
> | > Date: Fri Feb 10 17:33:02 UTC 2006
> | >
> | > Modified Files:
> | > src/sys/dev/wscons: wsmouse.c
> | >
> | > Log Message:
> | > PR/32794: Paul Shupak: Panic in wsmouse code.
> | > Checking the number of events after you've trashed the stack is not
> | > very useful. Instead, break out of the loop if we ran out, printing a
> | > message.
> | Maybe there should be assertions just before each attempt to modify
> | events[nevents] to ensure that nevents is low enough.
> I think it is fine for the non-loop cases (because it is obvious that
> they fit).
> | But... given the way the events vector is sized (to which you added a
> | comment), in which situation can it overflow?
> Well, we'll find out soon enough I guess. The logic is complicated with
> the repeat button mix.
But it doesn't add more events to the vector. It only sets up a callout
which acts independently of the input function. Note that the first
event is sent from within this function, so everything is the same as
was before (modulo the assertion).
> | > Also don't try to inject 0 events; reset our state instead. Maybe
> | > having
> | Theorically the input function is called when there is, at least, an
> | event to process (this is stated in a comment at the beginning of the
> | function). Therefore, nevents == 0 cannot happen, isn't it?
> Then we should change it to print a diagnostic if DEBUG or DIAGNOSTIC is
I'm just trying to understand why the reporter of PR 32794 got those
Julio M. Merino Vidal <firstname.lastname@example.org>
The Julipedia - http://julipedia.blogspot.com/