GNU bug report logs - #24206
25.1; Curly quotes generate invalid strings, leading to a segfault

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, johnw <at> gnu.org, schwab <at> linux-m68k.org, 24206 <at> debbugs.gnu.org
Subject: bug#24206: 25.1; Curly quotes generate invalid strings, leading to a segfault
Date: Tue, 16 Aug 2016 14:07:05 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> I've reviewed the changes you pushed to master for fixing this bug,
> and I must say that most of them look like purely stylistic changes,
> to make the code more to your personal liking.  The actual bugs were
> very few and minor, and didn't necessitate such thorough changes.

The changes were motivated by bug fixes, not style. Although the bugs were 
mostly minor (e.g., generating bogus NUL bytes due to miscounting) it's fine to 
fix minor bugs. I did change nearby style (indenting as per GNU style, switching 
some locals to C99-style decl-after-statement, etc.) but none of the changes 
were pervasive or were intended for the emacs-25 branch, and it's fine to make 
such changes in master.

One of the bugs was O(N**2) performance when reallocating a temporary buffer. 
While I was at it, I changed the code to allocate a small temp buffer on the 
stack to avoid a malloc/free in the usual case, which should be a small win. 
This accounts for many changes that a quick glance might give the mistaken 
impression of being stylistic.

> without any comments as to why we handle the input string as
> multibyte for the rest of the function, I think this will confuse
> someone down the road.

OK, I added some comments along those lines (see attached patch).

> I think the refactoring already introduced a
> regression.

This comment appears to be about changes made in May for Bug#23425, not about 
code changes I made recently. The May changes were not a regression; they were 
intended and are documented in etc/NEWS. Alan Mackenzie felt strongly that some 
changes were needed in this area. See commit 
433d366dc7b053048abf710d790ff62421dd1570.

> maybe we should just go to the original code, after fixing the
> immediate bugs, as I proposed in a patch yesterday?

No, the code in master should be uniformly better than what's in emacs-25.

It would be nice to have good tests for substitute-command-keys, of course. (We 
can all add this to our lists of things to do. :-)

[0001-Omit-substitute-command-keys-code-no-longer-needed.patch (text/x-diff, attachment)]

Previous Next

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