Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site topaz.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!columbia!topaz!gallaher From: gallaher@topaz.ARPA (Mike Gallaher) Newsgroups: net.emacs Subject: Unipress Emacs Bug Fixes (2 of 3) Message-ID: <2142@topaz.ARPA> Date: Thu, 30-May-85 08:21:25 EDT Article-I.D.: topaz.2142 Posted: Thu May 30 08:21:25 1985 Date-Received: Fri, 31-May-85 06:13:41 EDT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 771 # This is a shar archive. Extract with sh. echo Extracting hostname-1 cat > hostname-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: hostname-1 date: 24-May-85 posted-to: fixed-by: unipress!mg (Mike Gallaher @ Unipress Software) source-files: config.c lispfuncs.c Synopsis: Emacs did not use the hostname call under 4.2bsd Description: Emacs had always depended on the user to set the system name up in config.c. Under 4.2bsd this is silly, since there is a system call to return the system name at run time. Then one copy of Emacs can be moved around to a number of similar 4.2 machines without recompiling it. Fix: config.c Enclose the initialization of SystemName inside a conditional: #if SYS_4_2 == 0 char *SystemName = "unipress"; /* under 4.2, this is done instead by the hostname call in lispfuncs.c, so don't worry about setting it. */ #endif *************** lispfuncs.c Change the extern declaration of SystemName to #if SYS_4_2 char SystemName[SYSNAMELEN]; /* raw name of system */ #else extern char *SystemName; /* defined in config.c for non-4.2 */ #endif --------------- In InitFunc, after the defproc of "mark", there is a block of code that sets up ConvertedSystemName. Add another level of braces around it and add the four lines within the first level so that the code looks like this: defproc(MarkVal, "mark"); { #if SYS_4_2 int SysnameLength = sizeof(SystemName); gethostname(SystemName, &SysnameLength); #endif { char *p = SystemName; if (*p == 0) p = "Bogus System Name"; (void) strncpy(ConvertedSystemName, p, sizeof(ConvertedSystemName)); p = ConvertedSystemName; while (*p) { if (*p < ' ') *p = 0; else if (*p == ' ') *p = '-'; p++; } } } *************** __Egregious Trees!!!__ echo Extracting kbdmac-1 cat > kbdmac-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: kbdmac-1 date: 10-Apr-85 fixed-by: barnes@tl-20 (Gary Barnes) posted-to: source-files: macros.c Synopsis: Keyboard Macros defined with incorrect length Description: DefineStringMacro left off the last character of the macro. It turned out that DefMac copied one too few characters for the macro body. This happened to work for DefineKeyboardMacro and DefineBufferMacro because they passed a length argument that was the real length+1, but DefineStringMacro did not do this so it always got the last character chopped off. Fix: Make DefMac copy exactly the number of characters given by the length argument and fix DefineKeyboardMacro and DefineBufferMacro to pass exactly the length of the string they want to define. Apply the changes below, using the code in the #if FIXED sections. In the file macros.c: ************************ In the function DefMac, change the code as follows: #if FIXED while (macrolength--) /* {14} */ *t++ = *q++; /* {14} */ *t = '\0'; /* {14} */ #else while (--macrolength) *t++ = *q++; #endif ------------- In function EditMacro, change the code as follows: #if FIXED while (i--) { /* {14} had been --i */ (void) InsertAt(dot, *s++); DotRight(1); } #else while (--i) { (void) InsertAt(dot, *s++); DotRight(1); } #endif ------------- In function DefineBufferMacro, change the code as follows: #if FIXED (void) DefMac(bf_cur->b_fname, (char *) p1_cache + 1, MacroBound, s1_cache); /* {14} this had been s1_cache+1 */ #else (void) DefMac(bf_cur->b_fname, (char *) p1_cache + 1, MacroBound, s1_cache+1); #endif ------------- In function DefineKeyboardMacro, change the code as follows: #if FIXED (void) DefMac(name, (char *) KeyMem, MacroBound, MemUsed-1); /* {14} */ #else (void) DefMac(name, (char *) KeyMem, MacroBound, MemUsed); #endif ------------ end of patches to macros.c ------------------------------ __Egregious Trees!!!__ echo Extracting kbdmac-2 cat > kbdmac-2 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: kbdmac-2 date: 15-Apr-85 posted-to: fixed-by: rbbb@rice (David Chase @ Rice University) source-files: keyboard.c Synopsis: Keyboard macros have extra characters at the end Description: Keyboard macros had spurious characters tacked onto the end if the stop-remembering that ended them was invoked by a multi-key sequence. The old code had just subtracted one from the length, assuming that stop-remembering was bound to a two-key sequence. Fix: The fix, from David Chase @ Rice, uses a variable MemAtLastStroke to save the value of MemUsed when ProcessKeys started reading the last command sequence. In the file keyboard.c: ************************* Add the following variable definition after that of MemPtr: hidden int MemAtLastStroke; /* records MemUsed when ProcessKeys begins to walk keymaps {13} */ --------- In function ProcessKeys, change the code as follows (new code is as if FIXED were defined non-zero): #if FIXED if (NextGlobalKeymap == NULL) { NextGlobalKeymap = CurrentGlobalMap; MemAtLastStroke = MemUsed; /* {13} */ } #else if (NextGlobalKeymap == NULL) NextGlobalKeymap = CurrentGlobalMap; #endif --------------- In function GetChar: #if FIXED MemUsed = MemAtLastStroke; /* {13} had been MAXKBDMACLEN */ #else MemUsed = MAXKBDMACLEN; #endif --------------- In function StartRemembering: MemUsed = 0; #if FIXED MemAtLastStroke = 0; /* {13} */ #endif message(FALSE, Msg_remembering); ---------------- In function StopRemembering: #if 1 MemUsed = MemAtLastStroke; /* get rid of keystroke ending def {13} */ #else MemUsed -= 1; /* get rid of the ^x from ^xe (puke!) */ #endif ---------------- end of patch to keyboard.c ------------------------- __Egregious Trees!!!__ echo Extracting keymap-1 cat > keymap-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: 2.00 ident: keymap-1 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: keymap.c Synopsis: get-local-keymap complains about null keymap names Description: get-local-keymap generates an error if there is no local keymap. It should return a null string. Repeat-by: Execute (get-local-keymap) in a buffer that has no local keymap. It will signal an error. Fix: Replace the definition of keymap.c$GetLocalKeymap with the following code: visible int GetLocalKeymap() { char *name = MD_KEYS && MD_KEYS->name ? MD_KEYS->name : ""; MLvalue->exp_release = FALSE; ReturnStr(name); return(NULL); } __Egregious Trees!!!__ echo Extracting keymap-2 cat > keymap-2 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: keymap-2 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: keymap.c Synopsis: use-local-map complains if given null keymap name Description: The old behavior of use-local-map when given a null string [ie. (use-local-map "") ] was to give an error message saying that "" was not a keymap. A more useful behavior is for the function to remove whatever local keymap exists. For example: (setq oldmap (current-local-keymap)) (use-local-map "foo") .... MLisp code ....... (use-local-map oldmap) This code fragment will change the local keymap and then replace it with the old one, even if there was no old keymap. Repeat-by: Fix: In the C function UseLocalMap, an enclosing if statement must be added. Find the code fragment: if (b->b_binding != KeyBound) { .... } else .... and put that fragment inside this if statement where the four dots are; if (b->b_name[0]) { .... } else MD_KEYS = NULL; The if tests to see if the name of the boundname passed back by ProcArg is null. --------------- End of patches to keymap.c ------------------------------ __Egregious Trees!!!__ echo Extracting leftoffset-1 cat > leftoffset-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: leftoffset-1 date: 29-Apr-85 posted-to: fixed-by: nsc!glenn (Glenn Skinner @ National Semiconductor) source-files: buffer.h display.c Description: Buffers are not displayed properly if left-offset > 0, and the mode line is affected by the left-offset value. Repeat-by: Set left-offset to some non-zero value. Fix: In the file buffer.h, the definition of the MD_LEFTOFFSET macro is incorrectly ended with a semicolon. Remove the semicolon. In the file display.c, find the function setpos. The two statements at the beginning that manipulate LeftOffset are interchanged. The proper code should look like DSskip = MD_LEFTOFFSET - col + 1; col -= MD_LEFTOFFSET; __Egregious Trees!!!__ echo Extracting linenum-1 cat > linenum-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: 2.00, 2.01 ident: linenum-1 date: 21-May-85 posted-to: fixed-by: unipress!mg (Mike Gallaher @ Unipress Software) source-files: lispfuncs.c Synopsis: line-number hangs when invoked at end of buffer Description: The function line-number hangs if invoked when dot is at the end of a buffer. Repeat-by: (end-of-file) (line-number) Be prepared to kill the emacs from another terminal. Fix: In the file lispfuncs.c, the function LineNumber. The while loop depends on the NextLine always advancing dot, which does not happen if dot is already at the end of the buffer. Add a test after line is incremented to exit the loop if dot has reached its starting point. ------- begin patch to lispfuncs.c ------------------------------- while (dot <= old_dot) { NextLine(); line++; #if FIXED if (dot == old_dot) break; #endif } ------- End patch to lispfuncs.c ------------------------------- __Egregious Trees!!!__ echo Extracting macros-1 cat > macros-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: macros-1 date: 28-May-85 posted-to: fixed-by: barnes@tl-20.arpa (Gary Barnes @ Tartan Labs) source-files: macros.c Synopsis: defun'ing same name as the current local keymap -> core dump Description: When a function is defun'ed (or a macro is defined) with the same name as the current local keymap, Emacs doesn't realize that the keymap has gone away and tries to do keymap-ish things to where it used to be, even though its storage has been free'ed. Repeat-by: Execute the following MLisp: (define-keymap "orn") (use-local-map "orn") (defun (orn)) (current-local-keymap) (use-local-map "orn") Then type any command key. This will cause bizarre behavior and probably a core dump, usually the first time but you may need to execute it more than once to induce death. Fix: This one isn't solved yet. Though it doesn't fix the core dump, here is a fix for an error in code that is very likely related: On approximately line #230 in macros.c$DefMac there are two if-statements whose then clauses are comparisons (==) but should be assignments (=). 1) Change CurrentGlobalMap == &GlobalMap; to CurrentGlobalMap = &GlobalMap; 2) Change MD_KEYS == NULL; to MD_KEYS = NULL; (This argues for the NULL == MD_KEYS coding style...) --------------- End of patch to macros.c ------------------------------ __Egregious Trees!!!__ echo Extracting mchan41-1 cat > mchan41-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: mchan41-1 date: 29-May-85 posted-to: fixed-by: tjalk!sjoerd (Sjoerd Mullender) source-files: mchan4.1.c Synopsis: subprocesses inherit open files with fd > 2 Description: Subprocesses started by emacs inherit open files with file descriptors above 2. Fix: In the file mchan4.1.c, in the function start_process, look for the following code: (void)dup(newfd); (void)close(2); (void)dup(newfd); execlp(shname, shname, "-c", command, strcmp(shname+strlen(shname)-3,"csh")==0 ? "-f" : 0, 0); (void)write(1, "Couldn't exec the shell\n", 24); Add the following two lines just before the execlp line: for (newfd = 3; newfd < 20; newfd++) (void)close(newfd); --------------- End of patches to mchan4.1.c ------------------------------- __Egregious Trees!!!__ echo Extracting minibuf-1 cat > minibuf-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix ident: minibuf-1 Emacs version: 264, 2.00, 2.01 date: 13-May-85 posted-to: fixed-by: unipress!mg (Mike Gallaher @ Unipress Software) source-files: minibuf.c Synopsis: core dump on minibuffer commands >40 chars Description: Emacs core dumps when strings longer than 40 characters are inserted into the minibuffer all at once and then read as a command (or by anything that does getword). Repeat-by: Type ESC-x followed by some string more than 40 characters long with no embedded spaces (typing an unquoted space terminates the read). The same problem arises if you use ^Y to insert long strings into the minibuffer. When you type carriage return, Emacs tries to read the string as a command and core dumps. Fix: The problem is that the local prefix in getword was being overflowed by a strcpy. The fix is to ensure that the string does not grow too big by using strncpy and setting the last character position to \000. In the file minibuf.c in the function getword, change the code as follows: ------Begin patch to minibuf.c -------------------------------------------- Ding(); #if BUG (void) strcpy(prefix, word); #else (void) strncpy(prefix, word, sizeof(prefix)-1); /* {28} */ prefix[sizeof(prefix)-1] = '\0'; /* {28} */ #endif if (nfound == FALSE) { ------End patch to minibuf.c -------------------------------------------- __Egregious Trees!!!__ echo Extracting misc-1 cat > misc-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: misc-1 posted-to: date: 10-May-85 source-files: minibuf.c display.c mlprims.c errlog.c Synopsis: Various minor problems, not too serious Description: Miscellaneous fixes. ----------------------------------------------------------------------- minibuf.c change declaration of word from int to char * in function print_table. From nsc!glenn. minibuf.c at the end of BrGetstr, move the STATE(STATE_NORMAL) macro inside the block that did the STATE(STATE_MINIBUFINPUT). display.c A local variable in UpdateLine was not being initialized because the line was "... od = od = 0" where it should have been "... od = nd = 0". From nsc!glenn. mlprims.c In ProgN, the automatic rv is not being set in all cases. Change "int rv, saverr" to "int rv = 0, saverr". From nsc!glenn. errlog.c error-message-format had its default binding pointing at a string in pure space, so trying to set the default value caused core dump. Fixed by creating static DflErrorMsgFmt array: - enclose the DefStrVar's for [default-]error-message-format in curly braces - add the following lines just after the open brace: static char DflErrorMessageFormat[MAXERRFMTLEN]; (void) strcpy(DflErrorMessageFormat, DFL_ERRFORMAT); - while you are at it you can move the line strcpy(ErrorMessageFormat, DFL_ERRFORMAT); there too. --------------- __Egregious Trees!!!__ echo Extracting mlarith-1 cat > mlarith-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: 264, V2.00 ident: mlarith-1 date: 15-Mar-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: mlarith.c Description: The functions <<, >>, *, and ^ will hang if an error occurs while they are evaluating their arguments. Repeat-by: Execute the MLisp line (* some-undefined-variable bar) and be prepared to kill your Emacs from another terminal. Fix: The problem is that these functions never check the global error variable Emacs_Err (err under 264). If an error occurs while they are processing their arguments, they never notice and continue to try evaluating them. In the file mlarith.c (arithmetic.c in 264), in each of the functions shiftleft shiftright times xor there is a while loop. Change the condition of that while loop to terminate if Emacs_Err is TRUE, as in while (! Emacs_Err && EI.ArgN < EI.ArgMax) ------------------------------------------------------------------------- __Egregious Trees!!!__ echo Extracting mlisp-1 cat > mlisp-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: mlisp-1 date: posted-to: fixed-by: david medinets (unipress!dm) source-files: mlprims.c Synopsis: trying to defun a wired function causes core dump Description: When MLisp defuned a function with the same name as a wired primitive Emacs would core dump. This was be- cause when changing from an if to a case statement, the scope of the break statements in the function DefineFunc- tion were changed. Repeat-by: Execute the MLisp line (defun (backward-word (nothing))) Emacs will core dump if you have this bug. Fix: In the C function DefineFunction, there is a switch (b->b_binding) { .... } in the following case statement: case ProcBound: .... break; change the 'break;' to a 'goto dmm;' and insert this line: dmm: before the line containing: EI.Nis++; __Egregious Trees!!!__ echo Extracting overwrite-1 cat > overwrite-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: overwrite-1 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: simplecoms.c Synopsis: buffer-is-modified not being updated in overwrite mode Description: When making changes while in overwrite mode the buffer-is-modified variable was not getting updated (hence the '*' does not appear in the modeline). Repeat-by: 1> set a buffer in overwrite mode. 2> set buffer-is-modified to 0. 3> make some changes; 4> notice that the modeline has no '*' in it. Fix: In the C function simplecoms.c$SelfInsert, look for the if statement; if (mode_cache.md_Overwrite && CharAt(dot)!='0 && dot <= NumCharacters) { .... } Add the following lines to the end of the block: if (modified_buffer_cache == 0) Cant1LineOpt = TRUE; modified_buffer_cache++; This will update the buffer-is-modified variable and the test makes sure that the mode line is only updated for the first change. --------------- End of patch to simplecoms.c ------------------------------ __Egregious Trees!!!__ echo Extracting overwrite-2 cat > overwrite-2 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: overwrite-2 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: simplecoms.c Synopsis: overwrite mode does not check read-only status Description: The Overwrite mode did not check to see if a buffer had read-only set before making changes. Repeat-by: 1> set a buffer read-only. 2> try to type something, notice that you can't. 3> put the buffer into overwrite mode. 4> try to type something, notice that you can. Fix: In the C function simplecoms.c$SelfInsert, look for the if statement; if (mode_cache.md_Overwrite && CharAt(dot)!='0 && dot <= NumCharacters) { .... } Add the following lines to the beginning of the block: if (mode_cache.md_ReadOnly) { (void) sprintf(Err_buf, Err[Err_bufreadonly], bf_cur->b_name); error(Err_see_errbuf); return; } NOTE: This fix only applies to FULL_EMACS (as opposed to Minimacs). --------------- End of patch to simplecoms.c ------------------------------ __Egregious Trees!!!__ echo Extracting process-1 cat > process-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: process-1 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: mchan4.2.c Synopsis: ProcessID incorrectly reports error Description: In the C function ProcessID there is a mistake in the call to error. Repeat-by: Fix: In the C function mchan4.2.c$ProcessID, look for the if statment: if ((p_name = getstr(FALSE, Msg_getprocname)) == NULL) { .... } Change the block inside it to these two lines; (void) sprintf(Err_buf, "I need a process name."); error(Err_see_errbuf); __Egregious Trees!!!__