guest@csustan.UUCP (Chris Rhodes) (09/20/86)
( eat me. )
The following relates to curses on a Pyramid 90x running 4.2bsd:
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. Most of these give me a "Bus error
(core dumped)" message (one which I have generally gotten sick of)
but scanf() loses input, e.g.:
scanf("%s",buffer);
printf("%s",buffer);
prints nothing.
I ended up having to do a 'while ( (c = getchar()) != `\n`);'
structure which works, but I fear that I may be doing something
wrong which may cause other mysterious bugs.
Does this problem sound familiar with anybody else? Or is it
just another of those unique, mysterious curses bugs which can
be cured only by removing all traces of the program and spending
a month writing BASIC programs on a RSTS machine?
thanks in advance,
/* Chris Rhodes / Shooting Shark
* Currently cowering behind lll-crg!csustan!guest
* real uucp : lll-crg!csuh!shark -or- lll-crg!ptsfa!harlie!shark
* My opinions *are* those of csustan! Yeah, they made me spokesman, ah,
*/ president of the university! Yeah, *that's* the ticket!karl@haddock (09/22/86)
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');" >structure which works, but I fear that I may be doing something >wrong which may cause other mysterious bugs. I don't know if it's the same on 4.2bsd, but in SysV curses it isn't really safe to use stdio directly -- you should use the curses getch() function instead of getchar(). 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 used an identifier that accidentally collides with a global identifier from the library. (I had a similar problem with a program that had a global variable named "time".) Try using lint, if you have a decent lint library for curses. >Most of these give me a "Bus error (core dumped)" message (one which I have >generally gotten sick of) Have you considered examining the core dump? That's what it's for! Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
guido@mcvax.uucp (Guido van Rossum) (09/29/86)
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>