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 (1 of 3) Message-ID: <2141@topaz.ARPA> Date: Thu, 30-May-85 08:20:39 EDT Article-I.D.: topaz.2141 Posted: Thu May 30 08:20:39 1985 Date-Received: Fri, 31-May-85 06:13:17 EDT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 702 Here are some bug fixes for Unipress Emacs V2.00 and V2.01. This is the first of three shar archives. Unpack them into some directory and read the file README. If you have any questions, or find something wrong, send mail to unipress!mg. If there is no fix here for your favorite bug, let me know... Mike Gallaher Unipress Software ----------------------------------------------------------------- # This is a shar archive. Extract with sh. echo Extracting FORM cat > FORM << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: ident: date: posted-to: fixed-by: source-files: Synopsis: Description: Repeat-by: Fix: __Egregious Trees!!!__ echo Extracting INDEX cat > INDEX << "__Egregious Trees!!!__" Fixes for Unipress Emacs V2.00 and V2.01 2.01 -> 2.02 ------------ xonflow-2 setting xon/xoff-flow-control in startup files has no effect variables-3 setting GlobalModeString causes core dump filecmd-2 insert-file sets buffer read-only if file is write-protected abbrev-4 expanding abbrev for word > 200 chars causes core dump or hang hostname-1 Emacs did not use the hostname call under 4.2bsd abbrev-3 setting auto-write-abbrev-file core dumps abbrev-2 test-abbrev-expand checked global abbrevs before local leftoffset-1 incorrect display if left-offset variable > 0 linenum-1 line-number hangs when invoked at end of buffer mlarith-1 * << >> ^ hang if error in arguments subproc-1 FilterThrough, ExecBf use variable number of arguments syntax-1 dot-in-comment returns inverse of what it should unlink-1 unlink function does not work properly compiler-2 mlisp compiler trashes last byte of source strings filecmd-1 write-current-file incorrectly sets up buffer filename 2.01 -> 2.02 ------------ kbdmac-1 Keyboard macros defined with incorrect length kbdmac-2 Keyboard macros have extra characters at end minibuf-1 core dump on minibuffer commands >40 chars misc-1 Various minor problems, not too serious varfix-1 ++, --, +=, -=, etc. don't work with system variables xonflow-1 not easy to start Emacs in xon/xoff flow control mode 2.00 -> 2.01 ------------ abbrev-1 Abbrev tables forgotten across buffer changes args-1 ++, --, +=, etc. change their string variable arg to integer buffer-1 buffer modes (including keymaps) lost across buffer changes defun-1 trying to defun a wired function causes core dump comswitches-1 command line switches beginning with '+' cause core dump files-1 read-file incorrectly set up buffer file name gentty-1 no entry in gentty for SYS_III keymap-1 get-local-keymap complains about null keymap names keymap-2 use-local-map complains if given null keymap name overwrite-1 buffer-is-modified was not being updated overwrite-2 overwrite mode does not check read-only status process-1 ProcessID incorrectly reports error process-2 subproc.c won't compile on 8-character-unique preprocessors quit-2 bad command line switch causes core dump ttylock-1 ttylock.c won't compile properly if ONEEMACSPERTTY TRUE __Egregious Trees!!!__ echo Extracting README cat > README << "__Egregious Trees!!!__" This directory contains bug fixes for Unipress Emacs V2.00 and V2.01. They are listed in the file INDEX. If you have V2.00, all the fixes are applicable. If you have V2.01, the fixes that have only V2.00 in the version field have already been applied. The file FORM contains an empty bug fix form that you can fill out for fixes of your own. If you have any questions or want to point out problems, or have new fixes of your own, please send mail to unipress!mg. __Egregious Trees!!!__ echo Extracting abbrev-1 cat > abbrev-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: abbrev-1 date: posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: abbrev.c Synopsis: Abbrev tables forgotten across buffer changes Description: The abbrev tables can be local to a particular buffer. The location of these tables are stored in cache vari- ables so that they can be accessed and updated faster. The function SetBfp updates the buffer structure from the cache values. The problem is that abbrev.c is directly accessing the buffer structure. Repeat-by: Fix: The fix is to comment out or delete all the lines in the file abbrev.c with 'bf_cur->b_mode' in them. This can be done in the following way: Change the lines that look like this: bf_cur->b_mode.md_abbrev = mode_cache.md_abbrev = p; to look like this: #if 0 bf_cur->b_mode.md_abbrev = #endif 0 mode_cache.md_abbrev = p; AND Change the lines that look like this: bf_cur->b_mode.md_AbbrevOn = mode_cache.md_AbbrevOn = TRUE; to look like this: #if 0 bf_cur->b_mode.md_AbbrevOn = #endif 0 mode_cache.md_AbbrevOn = TRUE; __Egregious Trees!!!__ echo Extracting abbrev-2 cat > abbrev-2 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: 2.00, 2.01 ident: abbrev-2 date: 21-May-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: abbrev.c Synopsis: test-abbrev-expand checked global abbrevs before local Repeat-by: 1> Execute the following MLisp lines. (use-abbrev-table "a") (define-global-abbrev "but" "buttock") (define-local-abbrev "but" "no buts here") 2> Now type "but " in the buffer; it will expand to "no buts here"; this is correct. 3> Next type 'ESC-x test-abbrev-expand but' this will expand to "buttock"; this is the incorrect behavior; The correct expansion would have been "no buts here". Fix: There are two places that might need to be fixed depending on which version of the sources you have. Either way the changes to be made are the same, they are just made in different places. The problem is that when Emacs does a test-abbrev-expand, it first checks the local table and then check the global one. This order must be reversed. The checking is done in the file abbrev.c; in either the function TestAbbrevExpand or TstAbrExp2. The statement to look for is this: if ((p = lookup(&GlobalAbbrev, abbrev, h)) == NULL && (p = lookup(mode_cache.md_abbrev, abbrev, h)) == NULL) return(NULL); and you need to change it to this: if ((p = lookup(mode_cache.md_abbrev, abbrev, h)) == NULL && (p = lookup(&GlobalAbbrev, abbrev, h)) == NULL) return(NULL); Notice that the two statements are switched. __Egregious Trees!!!__ echo Extracting abbrev-3 cat > abbrev-3 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: abbrev-3 date: 23-May-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: mlvars.c Synopsis: setting auto-write-abbrev-file core dumps Description: Any attempt to set auto-write-abbrev-file results in a core dump because the variable was initialized wrong in mlvars.c. The problem is that the internal system variable AutoWriteAbbrevFile is initialized to point at a null string in initialized data space. Setting this variable tries to write the new value into this string; since it is not writable, this causes a core dump. Repeat-by: 1> ESC-x set auto-write-abbrev-file foo 2> Emacs will core dump. Fix: 1> In mlvars.c$InitMLvars change the extern statement for AutoWrAbFilename from an char pointer to an array declaration like this: extern char AutoWrAbFilename[PATHLEN+1]; 2> a little farther down in mlvars.c$InitMLvars is this line: AutoWrAbFilename = ""; change it to: *AutoWrAbFilename = '\0'; __Egregious Trees!!!__ echo Extracting abbrev-4 cat > abbrev-4 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: abbrev-4 date: 24-May-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: abbrev.c Synopsis: expanding abbrev for word > 200 chars causes core dump or hang Description: Trying to expand an abbrev phrase more than 200 characters long caused an array allocated on the stack to overflow, leading to bizzare behavior or a core dump. Repeat-by: 1) ESC-x set abbrev-mode 1 2) ^U300g this will insert 300 'g's in the buffer 3) (or any non-word character) this will cause Emacs to try to expand the abbrev for the word just typed, and will hang or core dump. Fix: In the function abbrev.c$AbbrevExpand there is a line: while (--n >= 1 && CharIs(c = CharAt(n), WordChar)) { change it to: while (p >= buf && --n >= 1 && CharIs(c=CharAt(n), WordChar)) { ^^^^^^^^^^^ --------------- End of patch to abbrev.c ------------------------------ __Egregious Trees!!!__ echo Extracting args-1 cat > args-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: args-1 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: mlargs.c Synopsis: ++, --, +=, etc. change their string variable arg to integer Description: When GetArg1 called StrToInt it did not check Emacs_Err to see if the arg was truly numeric; This resulted in the type of the variable being changed to integer no matter what its orginal type was. Repeat-by: Execute the MLisp (++ mode-line-format). mode-line-format will thereafter be an integer rather than a string. Fix: In the C function GetArg1, there is a switch statement: switch (e->exp_type) { .... } and inside that there is an if statement: case IsString: .... /* intentional fall-through */ right after the call to ReleaseExpr, add the following if statement: if (Emacs_Err) return(NULL); This checks the error return from StrToInt and returns if there was an error, preventing the rest of the code from changing the type to integer. __Egregious Trees!!!__ echo Extracting buffer-1 cat > buffer-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: buffer-1 date: 1-Apr-85 posted-to: fixed-by: david medinets (unipress!dm) source-files: buffer.c Synopsis: buffer modes (including keymaps) lost across buffer changes Description: Some buffer specific information, such as buffer specific variables, local keymaps, and region restrictions were being lost across buffer changes. Repeat-by: Fix: The permanent buffer structure of each buffer was not being updated when SetBfp was called. To fix, add a line of code to set the permanent buffer structure equal to the cache buffer structure in SetBfp. Add bf_cur->b_mode = mode_cache; to the end of the block inside this code fragment: if (bf_cur) { .... } --------------- End of patch to buffer.c -------------------- __Egregious Trees!!!__ echo Extracting compiler-1 cat > compiler-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: compiler-1 date: posted-to: fixed-by: david medinets (unipress!dm) source-files: mlprims.c Synopsis: 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 this MLisp line: (defun (backward-word (nothing))) and Emacs should 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 compiler-2 cat > compiler-2 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00, V2.01 ident: compiler-2 date: 22-May-85 posted-to: fixed-by: unipress!mg (Mike Gallaher @ Unipress Software) source-files: mlcompile.c Synopsis: mlisp compiler trashes last byte of source strings Description: The MLisp compiler, when called to compile a single string or word, replaces the last byte of the string with a \377 character. Repeat-by: Switch to an empty buffer, insert the string "foo", with the quotes, and do execute-mlisp-buffer. It will turn the last quote into a \377. This also shows up when you do (execute-mlisp-line "foo"); it will report the string executed as "fo\377". Fix: The problem is that while yylex (in mlcompile.c) is reading the source string via GETC, after reading EOF it pushes back the EOF via UNGETC. The current version of SrcUnGetC, which does the dirty work of UNGETC, merrily overwrites the last character with the EOF indicator, which is -1. The fix is to modify SrcUnGetC to refuse to do anything if the character is the EOF marker. Change the code as if FIXED were defined nonzero (this is only for illustration, the preprocessor will not accept this because of the backslashes quoting the newlines): #define SrcUnGetC(c, src) ((src)->strflg \ #if FIXED ? ((src)->snc && c != EOF \ #else ? ((src)->snc \ #endif ? ((src)->snc--,\ *--((src)->ssp) = c)\ : EOF)\ : ungetc(c, (src)->sfp)\ ) --------------- End of patch to mlcompile.c -------------------------- __Egregious Trees!!!__ echo Extracting comswitches-1 cat > comswitches-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: comswitches-1 date: 1-Apr-85 posted-to: fixed-by: unipress!mg (Mike Gallaher @ Unipress Software) source-files: emacs.c Synopsis: command line switches beginning with '+' cause core dump Description: Emacs core dumps if given a command line switch beginning with a '+', as in +457 (start at line 457) or +/vorm (start at string vorm). Repeat-by: Invoke Emacs using this command: emacs +100 foo.c Emacs will core dump if your version has this bug. Fix: In the file emacs.c, search for the code case '/': sstring = (*targv) + 2; break; default: if (isdigit(*targv[1])) { .... } change the if condition to: if (isdigit((*targv)[1])) { .... } --------------- End of patch to emacs.c ------------------------------ __Egregious Trees!!!__ echo Extracting defun-1 cat > defun-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: defun-1 date: 1-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) 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 core dumps. Repeat-by: Execute the MLisp line (defun (backward-word (nothing))) Emacs will core dump if you have this bug. Fix: In the C function mlprims.c$DefineFunction, look for the statement switch (b->b_binding) { .... } Within that switch, in the case clause case ProcBound: .... break; change the 'break;' to a 'goto dmm;' and insert this line: dmm: before the line containing: EI.Nis++; --------------- End of patch to mlprims.c ------------------------------ __Egregious Trees!!!__ echo Extracting filecmd-1 cat > filecmd-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.01 ident: filecmd-1 date: 30-Apr-85 posted-to: fixed-by: unipress!mg (Mike Gallaher @ Unipress Software) source-files: filecmds.c Synopsis: write-current-file incorrectly sets up buffer filename Description: When write-current-file (usually bound to ^X^S by default) is invoked in a buffer that has no associated file, it asks for one and writes that file. However, the next time anything asks for a file name interactively (e.g. visit-file), the name typed becomes the name associated with that buffer. Also, write-current-file will core dump if you type ^G when it asks you the name of the file to write. Repeat-by: ^Xbnonexist Switch to a new, file-less buffer. ^X^S/tmp/foo invoke write-current-file [the buffer will now have that name as its file] ^X^Vgralt visit a new file [the file gralt will now be visited in the buffer nonexist] Fix: The problem is that file names entered interactively are saved away in a static that gets overwritten the next time something asks for a file name. WriteCurrentFile just used that static. The fix is to save the string away in a safe place. The core dump on ^G happens because the code never checks to see if the returned argument is 0, as when ^G is typed, and tries to savestr it anyway. ------------------------------------------------------------------------ filecmds.c In function WriteCurrentFile, change the code as follows: #if FIXED if (! bf_cur->b_fname) { char *fn = GetFileName(prompt); if (STRNULL(fn)) { if (!Emacs_Err) /* if it wasn't aborted by ^G */ error(Err_emptyfilename); return(NULL); } else bf_cur->b_fname = savestr(SaveAbs(fn)); } #else not FIXED if (! bf_cur->b_fname) { if ((bf_cur->b_fname = SaveAbs(GetFileName(prompt))) == NULL) { error(Err_emptyfilename); return(NULL); } #endif FIXED __Egregious Trees!!!__ echo Extracting filecmd-2 cat > filecmd-2 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: 2.00, 2.01 ident: filecmd-2 date: 28-May-85 posted-to: fixed-by: unipress!dm (david medinets) source-files: filecmds.c Synopsis: insert-file sets buffer read-only if file is write-protected Description: Functions that read a file set the read-only variable in the buffer into which the file is being read, so that you will not try to modify the file. However, insert-file also behaves this way, which is annoying. Repeat-by: insert a file into your buffer that you know is write protected against you. You will notice that the status of read-only is TRUE. Fix: 1> In filecmds.c$InsertFile, add the variable declaration: int save_readonly = mode_cache.md_ReadOnly; 2> at the end of filecmds.c$InsertFile, and the following line: mode_cache.md_ReadOnly = save_readonly; --------------- End of patch to filecmd.c ------------------------------ __Egregious Trees!!!__ echo Extracting files-1 cat > files-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: V2.00 ident: files-1 date: 1-Apr-85 posted-by: fixed-by: source-files: fileio.c Synopsis: read-file incorrectly set up buffer file name Description: The function read-file asks whether you want to still read a file if the buffer that you are in is modified. The Emacs overwrites the name of the file that you are trying to read when it asks the question. Repeat-by: Visit a file, make some change to it, and say ESC-x read-file . Emacs will try to read a file with a bogus name into the buffer (but will not change the original file). Fix: In the C function fileio.c$ReadFile, change the first if statement from: if ((fn = GetFileName(": read-file ")) == NULL) { ... } to: if ((fn = SaveAbs(GetFileName(": read-file "))) == NULL && ! Emacs_Err) fn = SaveAbs(bf_cur->b_fname); --------------- End of patch to fileio.c ------------------------------ __Egregious Trees!!!__ echo Extracting gentty-1 cat > gentty-1 << "__Egregious Trees!!!__" Unipress Emacs Bug Fix Emacs version: 2.00 ident: gentty-1 date: 30-Apr-85 posted-to: fixed-by: unipress!dm (David Medinets @ Unipress Software) source-files: gentty.h Synopsis: no entry in gentty for SYS_III Description: The file gentty.h needs a system entry for SYS_III. This is easily accomplished because the entry for SYS_V will work for system 3. Fix: Find the line '#if SYS_V' and add '| SYS_III' to the end of it. __Egregious Trees!!!__