[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wgetch_events blocks unnecessarily

From: Thomas Dickey
Subject: Re: wgetch_events blocks unnecessarily
Date: Tue, 30 May 2006 09:33:22 -0400 (EDT)

On Tue, 30 May 2006, Bernd Jendrissek wrote:

Hash: SHA1

On Tue, May 30, 2006 at 08:41:03AM -0400, Thomas Dickey wrote:
On Tue, 30 May 2006, Bernd Jendrissek wrote:
            for (count = 0; count < 2; count++) {
                if ((mode & (1 << count))
                    && (fds[count].revents & POLLIN)) {
                    result |= (1 << count);

This is problematic if there is no SP->_mouse_fd but the caller still
requested mode with bit 1 set; in this case _nc_timed_wait() will be
accessing an uninitialized fds[count].revents.

ok - will look again.  I had some problem in mind when I was looking
at this on Saturday, but do not see it in the slice.

You're right - this isn't quite where the problem is.  IIRC the problem
is that the event list gets *populated* depending on whether there is a
SP->_mouse_fd or not, the the for loop above spills into the first user
_nc_event and sets bits in result.  That's exactly what I was seeing; my
serial port had data but result would indicate that my (nonexistent)
mouse was ready.

ok - I see what you're saying. I was only thinking in terms of whether the fd's from evt were initialized properly, but must change that '2' to reflect that it might spill into evt's list.

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]