GNU bug report logs - #23949
25.0.95; Regression in handling error caused by (string-match-p "." nil)

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> suse.de, 23949 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com
Subject: Re: 25.0.95;
 Regression in handling error caused by (string-match-p "." nil)
Date: Wed, 13 Jul 2016 12:00:40 -0400

>> > I also think that the "breaks a lot of Elisp code" part is at least a
>> > tad exaggerated.
>> Binding inhibit-changing-match-data to t will pretty much break any
>> function that uses match-beginning or match-end.
> But those functions aren't supposed to run when string-match is
> called.

Yet they are in bug#23949.

In practice, there's always a discrepancy between what is supposed to
happen and what can happen in the general case ;-)

>> > (defsubst string-match-p (regexp string &optional start)
>> >   "\
>> > Same as `string-match' except this function does not change the match data."
>> >   (condition-case err
>> >       (let ((inhibit-changing-match-data t))
>> > 	(string-match regexp string start))
>> >     (error (signal (car err) (cdr err)))))
>> That will still cause the same problems when debug-on-signal is non-nil.
> So you don't consider this an improvement that should be installed?

No.

A simpler and more robust solution would be
(save-match-data (string-match regexp string start))

Of course, with either solution, it means that string-match-p is even
worse in terms of efficiency, whereas the unsuspecting coder would
rightfully expect string-match-p to be (slightly) *more* efficient than
string-match.


        Stefan

Previous Next

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