GNU bug report logs -
#24206
25.1; Curly quotes generate invalid strings, leading to a segfault
Previous Next
Reported by: Phil <p.stephani2 <at> gmail.com>
Date: Thu, 11 Aug 2016 18:57:02 UTC
Severity: normal
Found in version 25.1
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii wrote:
>> Some change in this area was needed because the 'multibyte' flag went away.
>
> Only because you removed it. You could have left it alone, it would
> have worked
Sure, but it was no longer necessary, as the code no longer needs to record
whether the original string was multibyte. Keeping an unnecessary variable
around would make the code harder to read.
> even after the call to Fstring_make_multibyte, for the
> reasons I explained earlier: the result is not necessarily a multibyte
> string.
That doesn't affect the fact that the 'multibyte' variable is no longer
necessary. In emacs-25, 'multibyte' does not mean that the result is a multibyte
string; it means that the input is a multibyte string. There is no need to keep
track of that in master now, and it simplifies the code to not worry about it.
>> While doing that, I noticed that discarding all the code made this
>> somewhat-tricky area easier to follow. It's not merely that the old multibyte
>> code is unnecessarily long and hard to follow; it's that the old code does
>> something fairly-typical (copy a multibyte character) in an unusual way, which
>> is too likely to lead the reader into incorrectly thinking that there is
>> something actually unusual about the action.
> I don't see why it is tricky, we do that in Emacs in other places.
Really? A call to STRING_CHAR_AND_LENGTH followed by a length test followed by a
call to memcpy for length > 1 and a special case inline copy for length == 1?
When copying multibyte data? Where else does Emacs do that?
> it's more clear for you
Replacing 14 unusually and unnecessarily tricky lines with zero lines should
help clarify things for most readers.
> I could simply revert your commit, it would have saved us both quite
> some time. Would you prefer that?
It'd be even simpler to leave things alone, as the master code works better than
emacs-25 does. (Merely reverting the commit wouldn't suffice, of course.)
>> This one is not merely a style change. The old code matched \[ even if not
>> followed by ], the new code does not. This is an intended improvement. I plead
>> guilty to the charge that the new code is also shorter and clearer.
>
> Then why is there nothing about this in the log entry?
I didn't think such detail was necessary, since it was a change to undocumented
behavior. If you think it worth mentioning, I can add a NEWS item.
>> Alan wanted something that he could put into his .emacs that would cause
>> (message PERCENTLESS) to output the string PERCENTLESS as-is, assuming
>> PERCENTLESS lacks %. This was the point of his original bug report; his original
>> example involved ` and ' but he wanted the same behavior for ‘ and ’, a point
>> that became clear during the discussion of Bug#23425.
>
> Then why not for '..' as well? How is that different from ‘..’?
It's not different. Alan wanted the same behavior for '..', and he got that too.
This bug report was last modified 8 years and 339 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.