Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!lll-crg!seismo!mcvax!guido From: guido@mcvax.uucp (Guido van Rossum) Newsgroups: net.lang.c Subject: Re: String input problems in curses Message-ID: <7089@boring.mcvax.UUCP> Date: Mon, 29-Sep-86 15:17:52 EDT Article-I.D.: boring.7089 Posted: Mon Sep 29 15:17:52 1986 Date-Received: Wed, 1-Oct-86 05:55:13 EDT References: <183@csustan.UUCP> <86900065@haddock> Reply-To: guido@boring.uucp (Guido van Rossum) Organization: "Stamp Out BASIC" Committee, CWI, Amsterdam Lines: 37 Summary: It's more than likely that the bug went undetected so long Apparently-To: rnews@mcvax 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