GNU bug report logs - #29343
Match data doesn't contain elements for trailing non-matched subgroups

Previous Next

Package: emacs;

Reported by: Philipp Stephani <p.stephani2 <at> gmail.com>

Date: Fri, 17 Nov 2017 20:12:01 UTC

Severity: minor

Found in version 27.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 29343 <at> debbugs.gnu.org
Subject: Re: bug#29343: 27.0.50; Match data doesn't contain elements for
 non-matched subgroups
Date: Sat, 16 Dec 2017 14:29:12 +0000
[Message part 1 (text/plain, inline)]
Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 17. Nov. 2017 um
21:12 Uhr:

>
> $ emacs -Q -batch -eval '(progn (string-match "^\\(a\\)?\\(b\\)\\(c\\)?$"
> "b") (print (match-data)))'
> (0 1 nil nil 0 1)
>
> Note that neither the `a` nor the `c` group matched, but there are
> entries for `a` in `match-data`, but not for `c`.  This makes working
> with the match data unnecessarily hard because its length depends on
> whether certain optional groups have matched or not.  I haven't seen any
> discussion about this behavior in either the manual or the docstring.  I
> think the match data in this case should be (0 1 nil nil 0 1 nil nil).
>
>
It turns out that this is harder than I expected, because the information
about the number of groups in the pattern isn't stored anywhere, and
search_regs.num_regs may be different from the group count. If it turns out
too hard to fix, the behavior should at least be documented.
[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 117 days ago.

Previous Next


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