> [Cristian Idbohm:]
> > On the 'crisv32' (result after typing a single 'f'):
>
> > # ./rltest1.1
> > Enter a line:
> > Disappointingly, I couldn't even stuff a single 'f' into
> > readline's 512-byte long input queue, giving up :-(
>
>
> What is strange here is that rl_stuff_char() returns 0 (i.e. an error value)
> at the first keystroke (the double echoing on the i686 is to be expected,
> due to an superfluous rl_stuff_char() call that I forgot to edit out - but
> that is irrelevant to the problem at hand.)
>
> However close I look into input.c in the readline sources I cannot
> understand how such a thing could ever happen before the input queue has
> filled up, even before *anything *has been put into it.
The only way I can see this happening is that push_index and pop_index are
not initialized to 0 by the compiler. ibuffer_len is explicitly initialized,
so that can't be it. That's the only way ibuffer_len() can return an error,
and force rl_stuff_char to return 0.
I'd put a breakpoint at ibuffer_space() and examine those three variables.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-readline mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-readline
