guido@boring.UUCP (01/02/85)
I don't believe there is a mod.sources.bugs newsgroup, so I post this here.
I successfully unpacked all eleven parts of the terminfo distribution, and
they indeed all compiled without complaints on our 4.2 BSD system.
Then I tried to test it. Great disaster. The test program provided,
mille, didn't run. There were several problems. After I fixed the trivial
ones, I still got core dumps immediately after starting it up. Has anybody
come this far?
(Here is a list of the trivial problems.
- putchar('') in a certain file -- I assume bells were eaten
by a mailer underway. Anyway, the correct way to put a bell
in a string is '\7'
- #include <time.h> -- must be <sys/time.h> on BSD systems
- libpcurses not found -- used libdcurses)
The nontrivial problem is:
- memory fault - core dumped, immediately.
in: delwin(0), from: main(...).
I thought this was caused by mille.h #including <curses.h>,
which (in my interpretation of the cc manual) will always use the old
curses. Changed into "../../=src/curses.h".
But the same problem occurs.
Anybody got a clue? The system looks like a good one from the documentation
and what I've seen of the source code; it would be a pity not to use it, but
right now I don't have the stomach (nor time) for debugging it.
Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
guido@mcvax.UUCPguido@boring.UUCP (01/04/85)
In article <6273@boring.UUCP> I asked help with running the test program, mille, for the terminfo library. I got two replies, telling me that the program has a bug, namely it doesn't check the return of initscr(), and if there is something wrong with the TERM or TERMINFO environment variables (so the definition can't be found), initscr() fails but mille continues as if all is well. It then crashes when it passes garbage to delwin(). I made the following simple fix to mille: change the initscr() call to: if (initscr() == ERR) { printf("Sorry. No terminal description found."); printf(" (Check TERM or TERMINFO variables)\n"); exit(-1); } We have a compatibility problem here. Good ol' curses' initscr() would never fail -- if nothing was found out about the terminal, it would assume a paper tty, and at least output some garbage. Therefor probably every program in the world that used curses has to be changed in this respect. System V wizards -- is this true in the system V terminfo library too? Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido@mcvax.UUCP "Immorality may be something, but it does not take the place of virtue and three square meals a day."
mark@cbosgd.UUCP (Mark Horton) (01/06/85)
The System V curses is slightly different from either of the two cases you describe. If there is an error in initscr, an error message is printed and the program exits. initscr will not return under such circumstances. (If you want to catch the error, there is a lower level routine you can call instead of initscr that will return a detectable error status.) There is no reason to modify programs to check stdscr after calling initscr. If anything, perhaps the posted initscr should be changed. The interface between the application program and curses is more important than any particular implementation of curses.