[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] emacs-25 ee04aed: Fix handling of buffer relocation in

From: Eli Zaretskii
Subject: Re: [Emacs-diffs] emacs-25 ee04aed: Fix handling of buffer relocation in regex.c functions
Date: Tue, 25 Oct 2016 19:22:36 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 25 Oct 2016 08:20:25 -0400
> > The same is true for many other parts of Emacs: bidi.c, syntax.c,
> > composite.c, to name just a few.
> I think it's worse because the answer to the question depends on
> potentially the whole code (e.g. changing a piece of code such that it
> now uses malloc means you have to check every caller (and caller's
> caller, ...), and in other direction, when manipulating buffer text you
> need to check every function you call (and the functions they call, ...)
> to see if they may call malloc).

True.  But OTOH, the number of places where we call BYTE_POS_ADDR and
then manipulate the result as a 'char *' is quite small.

> > Sure.  But we're already in the minefield, might as well be careful
> > enough to not step on any mine, until we can get out.
> I think we can get out right away.

No, not yet.  First, we need to make sure that removing ralloc.c from
the build works well and doesn't cause memory fragmentation or other
unwanted side effects, and we need to do that both on GNU/Linux and on
other supported platforms we care about, like *BSD.  If some of these
experience problems, we need to solve them, preferably without using
ralloc.c.  Only when there are no more platforms that use ralloc.c can
we remove all those workarounds from the code.

I agree that there's a good chance we'll achieve this goal soon
enough, but we are not there yet.  We just made the first step today
in that direction.  I'm not even sure we will be able to achieve this
goal before Emacs 25.2 is released.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]