GNU bug report logs - #31888
27.0.50; Segmentation fault in replace-buffer-contents

Previous Next

Package: emacs;

Reported by: MichaƂ Kondraciuk <k.michal <at> zoho.com>

Date: Mon, 18 Jun 2018 21:00:04 UTC

Severity: normal

Found in version 27.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #52 received at 31888 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, k.michal <at> zoho.com, joaotavora <at> gmail.com, 31888 <at> debbugs.gnu.org
Subject: Re: bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents
Date: Fri, 29 Jun 2018 16:40:15 -0400
>> Keep track of the first and last char actually modified (or,
>> equivalently, keep track of the number of chars unmodified at the
>> beginning and at the end, as this is often easier).
>
> Is that worth the hassle?  The caller asked to replace the entire
> buffer by something else, why should they expect after-change hooks to
> be run on something other than the entire buffer?

IIUC replace-buffer-contents is meant to be used in cases where there's
a good probability that the old and new contents are almost identical,
save for a few details here and there.

So, it may very well be the case that out of the 1MB that is covered by
BEGV..ZV only 10bytes in the middle were deleted/inserted/modified, in
which case running a-c-f on those 10bytes will likely lead to
a significantly more efficient recomputation for things like font-lock.

This refinement is not indispensable, but we make this effort in pretty
much every other similar circumstance.  It's usually fairly easy/cheap
to provide those tighter bounds.


        Stefan




This bug report was last modified 6 years and 327 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.