dlnash@ut-ngp.UUCP (Donald L. Nash) (08/06/87)
There is a bug in MicroEMACS 3.8l having to do with editing the startup file.
I noticed that when I tried to do this, unpredicable results would occur.
The most violent results occurred under VMS, where it would bomb with
an access violation. After tracing through the program with VMS Debug,
I discovered the problem. Here is what is going on:
$ emacs sys$login:emacs.rc
1. Parse the command line.
A. The only thing on the command line is the name of a file to edit,
so create a buffer for that file, but do not read in the file yet.
The buffer name is "emacs.rc".
2. Execute the startup file.
A. Create a buffer for the startup file. Since the startup file is
called emacs.rc, the buffer is also called emacs.rc. The function
which creates buffers first checks to see if a buffer by that
name already exists. If it does, it simply returns a pointer
to it rather than creating a new buffer. Since we just created
a buffer called "emacs.rc" in the previous step, we get a pointer
to it.
B. Read in the file and execute it.
C. Delete the buffer. *** WE ARE NOW IN REALLY BAD SHAPE. ***
3. Now try to read in the edit file into the buffer created in step 1.
Unfortunately, this buffer was deleted in step 2c. Unpredicable
things now occur, the most reasonable of which occurs under VMS,
which is to get nailed with an access violation because of a wild
pointer reference.
The fix is very easy. In the file exec.c, in function dofile(), there is
a call to makename(bname, fname). After this, insert a call to
unqname(bname) to make sure that the buffer name is unique before trying
to create it with bfind(). That's all there is to it!
Don Nash
UUCP: ...!{ihnp4, allegra, seismo!ut-sally}!ut-ngp!dlnash
ARPA: dlnash@ngp.UTEXAS.EDU
BITNET: CCEU001@UTADNX, DLNASH@UTADNX
TEXNET: UTADNX::CCEU001, UTADNX::DLNASH
UUU UUU
U U The University of Texas at Austin
U TTTTUTTTTTTTTT Computation Center
U T U TT T
U U TT "The world is basically non-linear."
UUUUUUU TT
TT
TTTT