Re: a bug of read-passwd

[Richard Stallman]

    OK, I looked into this.  I think that fixing read-event to give it a
    new argument specifying a max delay turns out to be not simple to
    implement.

I think it is not so hard.

    (The detailed situation is this: the old sit-for called
    wait_reading_process_output for a given duration, but that's
    problematic since wait_reading_process_output can return due to fake
    events.  The new sit-for solves this by calling read-event, which
    relies on read_char, which loops calling wait_reading_process_output
    with zero duration and discarding fake events [using
    kbd_buffer_get_event, which does some complicated processing to figure
    out if the event is fake or not].

It would work right if sit-for passes down to wait_reading_process_output
the fact that it has a timeout.


                                       The new sit-for interrupts this
    loop using a timer.  If we want to hack read_char to accept a new arg
    specifying the max delay, there would be two sets of timing code:
    inside read_char, and inside wait_reading_process_output.

read_char needs to do arithmetic so it can recompute the remaining
timeout, in case wait_reading_process_output returned an event
which got discarded.  But this is not very hard.  Just add the
specified timeout to the current time, at the start, and subtract
the current time before each call to wait_reading_process_output.

wait_reading_process_output does this same computation in order
to call select with the proper remaining timeout.

The inelegance of this is just a matter of repeating a little code.
At the deeper level, this design is elegant because it is very safe.
So I think we should try it.

The superficial inelegance can be removed easily if
wait_reading_process_output accepted an ending time, rather than a
duration.  That way, the addition would only be done once at the
outset, and the subtraction would only have to be done when
wait_reading_process_output is about to call select.