davidsen@steinmetz.ge.com (William E. Davidsen Jr) (12/20/88)
When getting control strings from the termcap in tcapopen (UNIX only), the result is not check to see if the string is not present. This results in a call to strcpy with the NULL string as the source, and will cause a memory fault on some machines. As before this is for the separate version of tcap.c, not the one included in emacssrc.arc. When the VT100 option is used, I'm not sure that the keystrokes should even be loaded, but they shouldn't cause a memory fault. **** tcap.c 190c190,191 < strcpy(ttable[index].p_seq, tgetstr(ttable[index].p_name, &p)); --- > if (t = tgetstr(ttable[index].p_name, &p)) > strcpy(ttable[index].p_seq, t); -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
nwd@j.cc.purdue.edu (Daniel Lawrence) (12/20/88)
In article <12827@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > > When getting control strings from the termcap in tcapopen (UNIX only), >the result is not check to see if the string is not present. This >results in a call to strcpy with the NULL string as the source, and >will cause a memory fault on some machines. > > As before this is for the separate version of tcap.c, not the one >included in emacssrc.arc. > > bill davidsen (wedu@ge-crd.arpa) Bill, The version you looked at was one sent to me to solve some system V UNIX problems. He had worked off an older copy of tcap.c. I had fixed the tgetstr problem already in the distribution sources, and only merged in the changes from this new tcap.c... so all should be fixed for the release. I am still aghast at the variety of different timing functions and delay functions for V5 (Xenix, Sun, Microport.. etc) and it looks like we will end up with yet another group of machine dependant defined to cover these. The 3.10 release is still scheduled for this sunday (Christmas.....). Daniel Lawrence (317) 742-5153 nwd@j.cc.purdue.edu The Programmer's Room Fido 1:201/10 (317) 742-5533