Date:	Sun, 14 Apr 1996 20:05:02 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	DJ Delorie <dj AT delorie DOT com>
Cc:	terra AT diku DOT dk, djgpp-workers AT delorie DOT com
Subject:	Re: new write.c
In-Reply-To:	<199604141648.MAA23680@delorie.com>
Message-Id:	<Pine.SUN.3.91.960414195445.3098D-100000@is>
Mime-Version:	1.0

On Sun, 14 Apr 1996, DJ Delorie wrote:

> write() was a special case for emacs, which write()s the file out but
> has a special malloc that may move your buffer out from under you
> whenever you call it.

Just FYI: I've spent an evening grepping through all the library sources
and Emacs sources to be sure no other place in Emacs has a potential for
these problems.  Of course, there are other places!  The only thing that
saves us (and others) is that currently this relocation only happens with
Emacs buffers, so if the pointer you get is to some other object, you are
supposedly safe (says RMS).  But I'm not entirely sure (and have no way to
check it without spending too much time) that some obscure option in some
obscure command won't ever pass a pointer to a part of a buffer when it
usually passes, say a string.  E.g., consider the packages that expand the
word at point.  My only hope is that such problems will be also seen on
other platforms.  So making as few of the library functions as we can call
`malloc' might be a good design goal. 

(Personally, I think it's crazy to make such relocations in a C program.  
When I saw that buffer move from under my feet, I was so shocked I didn't 
even believe my eyes until RMS confirmed that this was indeed happening.)

- Raw text -