[Top][All Lists]

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

bug#24206: 25.1; Curly quotes generate invalid strings, leading to a seg

From: Paul Eggert
Subject: bug#24206: 25.1; Curly quotes generate invalid strings, leading to a segfault
Date: Tue, 16 Aug 2016 14:07:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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

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. :-)

Attachment: 0001-Omit-substitute-command-keys-code-no-longer-needed.patch
Description: Text Data

reply via email to

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