[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questionable code in handling of wordend in the regexp engine in reg
From: |
Alan Mackenzie |
Subject: |
Re: Questionable code in handling of wordend in the regexp engine in regex-emacs.c |
Date: |
Mon, 25 Feb 2019 18:56:56 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Stefan.
Sorry about the delay in replying.
On Sat, Feb 23, 2019 at 18:15:55 -0500, Stefan Monnier wrote:
> > Primarily, there is an
> > UPDATE_SYNTAX_TABLE (charpos);
> > before determining the syntax of the previous character, which seems OK.
> > Later on, before determining the syntax of the next character, we have:
> > UPDATE_SYNTAX_TABLE_FORWARD (charpos);
> > . Between these two calls, charpos hasn't been changed.
> Good spotting.
Thanks!
> > Surely the argument to the second occurrence should be (charpos + 1)?
> I believe it's instead the other one that needs to use "charpos - 1"
> because the UPDATE_SYNTAX_TABLE is called just before reading the char
> *before* charpos (see patch below).
I don't think this is right. offset is calculated from d, and then
decremented, before calculating charpos.
> > Also, probably less importantly, there is
> > GET_CHAR_AFTER (c2, d, dummy);
> > , whereas at the same place in the handler for case symend: we have
> > instead
> > c2 = RE_STRING_CHAR (d, target_multibyte);
> > . Is the effect of these macros identical, or is one of them up to
> > date, and the other one really needs updating as well, for correct
> > functionality?
> According to my reading of the code, they're identical in multibyte
> buffers not in unibyte buffers where RE_STRING_CHAR just returns a value
> between 0 and 255 (i.e. ASCII or Latin-1 more or less), whereas
> GET_CHAR_AFTER will return either an ASCII char (0..127) or a raw-byte
> char (4194176..4194303).
OK.
> I think it's more correct to return a raw-byte char (4194176..4194303),
> so I'd tend to think that GET_CHAR_AFTER is the better choice, but
> please don't quote me on this.
I won't say a word!
> > I came across these whilst investigating bug #34525. Making the
> > indicated changes to regex-emacs.c sadly doesn't help solve the symptoms
> > of that bug. :-(
> Does the patch below help?
Unfortunately not, not for bug #34525. I did try it out, though. In the
mean time, I've advanced somewhat in the debugging.
> Stefan
> diff --git a/src/regex-emacs.c b/src/regex-emacs.c
> index b667a43a37..72fb5ec561 100644
> --- a/src/regex-emacs.c
> +++ b/src/regex-emacs.c
> @@ -4813,7 +4813,7 @@ re_match_2_internal (struct re_pattern_buffer *bufp,
> re_char *string1,
> int dummy;
ptrdiff_t offset = PTR_TO_OFFSET (d) - 1;
> ptrdiff_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset);
> - UPDATE_SYNTAX_TABLE (charpos);
> + UPDATE_SYNTAX_TABLE (charpos - 1);
> GET_CHAR_BEFORE_2 (c1, d, string1, end1, string2, end2);
> s1 = SYNTAX (c1);
--
Alan Mackenzie (Nuremberg, Germany).