🚀 go-pugleaf

In article <86900065@haddock> karl@haddock writes:
>
>csustan!guest (Chris Rhodes) writes:
>>while designing a particular application using curses, the UNIX
>>terminal control package, I have found that *none* of the string
>>input functions work - not gets, scanf, or wscanw or any of the
>>other curses input routines.
>>I ended up having to do a "while ( (c = getchar()) != '\n');"
>
>But you say wscanw() etc. are also failing?
>
>Assuming it isn't a curses bug (if so, you'd think someone else would have
>found it by now -- it looks pretty serious!), I'd guess that you've [etc].

I don't know about Sys5, but in BSD curses there certainly bugs in scanw
and friends.  All I remember about the matter now is that it had
something to do with echoing and processing of erase/kill and control
characters, and also a blatant lack of boundary checking.
I ended up doing everything myself, which is what almost any serious
user of curses has to do anyway.  Maybe this is why the problems go
undetected and unsolved.  Other possible causes: in certain variants of
cbreak/raw mode (actually, when CRNL mapping is turned off; maybe
curses uses this itself because it also affects output of \n
characters), you never see a '\n' as input: the CR key is input as '\r'
(Oh, this is certainly one of the bugs in wgetstr: it only checks for
'\n').  And finally, there is an ominous comment in the source code about
matching with implementation details of _doscan.  I can easily see that
a port of this code passes testing ("hack still compiles and works, so
curses must be OK") without the scan stuff working.  (Btw, the printw
stuff may have a similar dependency.)

Oh, Karl: usually your comments are to the point, but this time your
remarks about "that's what core dumps are for" sounded a bit like RTFM
sarcasm.  I wouldn't blame someone for ignoring the core dump when the
source code to the malfunctioning routines is not even available!

	Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>