GNU bug report logs - #6388
Should not match data be set on misses?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6388 in the body.
You can then email your comments to 6388 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Emacs Bugs <bug-gnu-emacs <at> gnu.org>
Subject: Should not match data be set on misses?
Date: Thu, 10 Jun 2010 02:42:59 +0200

(let ((ret (re-search-forward "some weird thing" (point-at-eol) t)))
  (message "ret=%s, mb0=%s, 1" ret (match-beginning 0) (match-beginning 1)))

gives me messages like

   ret=nil, mb0=517, 1

I expected

   ret=nil, mb0=nil, nil

Message #10 received at 6388-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 6388-done <at> debbugs.gnu.org
Subject: Re: bug#6388: Should not match data be set on misses?
Date: Wed, 09 Jun 2010 22:03:08 -0400

> From: Lennart Borgman <lennart.borgman <at> gmail.com>
> Date: Thu, 10 Jun 2010 02:42:59 +0200
> Cc: 
> 
> (let ((ret (re-search-forward "some weird thing" (point-at-eol) t)))
>   (message "ret=%s, mb0=%s, 1" ret (match-beginning 0) (match-beginning 1)))
> 
> gives me messages like
> 
>    ret=nil, mb0=517, 1
> 
> I expected
> 
>    ret=nil, mb0=nil, nil

I'm closing this bug report because the ELisp manual explicitly
documents the current behavior:

      Every successful search sets the match data.  Therefore, you should
   query the match data immediately after searching, before calling any
   other function that might perform another search.  Alternatively, you
   may save and restore the match data (*note Saving Match Data::) around
   the call to functions that could perform another search.

      A search which fails may or may not alter the match data.  In the
   past, a failing search did not do this, but we may change it in the
   future.  So don't try to rely on the value of the match data after a
   failing search.

Patches welcome to "change this in the future" (unless Stefan or
Yidong object to such a change).

Message #11 received at 6388-done <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6388-done <at> debbugs.gnu.org
Subject: Re: bug#6388: Should not match data be set on misses?
Date: Thu, 10 Jun 2010 04:25:13 +0200

On Thu, Jun 10, 2010 at 4:03 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman <at> gmail.com>
>> Date: Thu, 10 Jun 2010 02:42:59 +0200
>> Cc:
>>
>> (let ((ret (re-search-forward "some weird thing" (point-at-eol) t)))
>>   (message "ret=%s, mb0=%s, 1" ret (match-beginning 0) (match-beginning 1)))
>>
>> gives me messages like
>>
>>    ret=nil, mb0=517, 1
>>
>> I expected
>>
>>    ret=nil, mb0=nil, nil
>
> I'm closing this bug report because the ELisp manual explicitly
> documents the current behavior:
>
>      Every successful search sets the match data.  Therefore, you should
>   query the match data immediately after searching, before calling any
>   other function that might perform another search.  Alternatively, you
>   may save and restore the match data (*note Saving Match Data::) around
>   the call to functions that could perform another search.
>
>      A search which fails may or may not alter the match data.  In the
>   past, a failing search did not do this, but we may change it in the
>   future.  So don't try to rely on the value of the match data after a
>   failing search.

Oh, thanks Eli, sorry for the trouble. I just could not imagine that
this was the "intended" behavior.

> Patches welcome to "change this in the future" (unless Stefan or
> Yidong object to such a change).

I will keep it in mind.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 6388 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org
Subject: Re: bug#6388: Should not match data be set on misses?
Date: Thu, 10 Jun 2010 09:04:08 -0400

> I'm closing this bug report because the ELisp manual explicitly
> documents the current behavior:

>       Every successful search sets the match data.  Therefore, you should
>    query the match data immediately after searching, before calling any
>    other function that might perform another search.  Alternatively, you
>    may save and restore the match data (*note Saving Match Data::) around
>    the call to functions that could perform another search.

>       A search which fails may or may not alter the match data.  In the
>    past, a failing search did not do this, but we may change it in the
>    future.  So don't try to rely on the value of the match data after a
>    failing search.

> Patches welcome to "change this in the future" (unless Stefan or
> Yidong object to such a change).

Yes, there was a long discussion about this a few years ago.  The main
obstacle to such a change are:
- it breaks some code.
- it is not tremendously useful.
- it is difficult to detect code that relies on the current behavior
  (so it's difficult to output a warning to help in the migration).
The current behavior is not tremendously useful either, of course, but
it has the advantage of being what we've used for many years.


        Stefan

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6388 <at> debbugs.gnu.org
Subject: Re: bug#6388: Should not match data be set on misses?
Date: Thu, 10 Jun 2010 15:35:17 +0200

On Thu, Jun 10, 2010 at 3:04 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> I'm closing this bug report because the ELisp manual explicitly
>> documents the current behavior:
>
>>       Every successful search sets the match data.  Therefore, you should
>>    query the match data immediately after searching, before calling any
>>    other function that might perform another search.  Alternatively, you
>>    may save and restore the match data (*note Saving Match Data::) around
>>    the call to functions that could perform another search.
>
>>       A search which fails may or may not alter the match data.  In the
>>    past, a failing search did not do this, but we may change it in the
>>    future.  So don't try to rely on the value of the match data after a
>>    failing search.
>
>> Patches welcome to "change this in the future" (unless Stefan or
>> Yidong object to such a change).
>
> Yes, there was a long discussion about this a few years ago.

Sorry, forgot.

> The main
> obstacle to such a change are:
> - it breaks some code.

Aka it makes some bugs (bad assumptions) surface. That is not always bad.

> - it is not tremendously useful.

But it is probably what a user/programmer normally expects.

> - it is difficult to detect code that relies on the current behavior
>  (so it's difficult to output a warning to help in the migration).
> The current behavior is not tremendously useful either, of course, but
> it has the advantage of being what we've used for many years.

Yes, that is true. However the current behavior probably wastes a lot
of time for those unaware of it.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 6388 <at> debbugs.gnu.org
Subject: Re: bug#6388: Should not match data be set on misses?
Date: Thu, 10 Jun 2010 14:57:01 -0400

>> The main obstacle to such a change are:
>> - it breaks some code.
> Aka it makes some bugs (bad assumptions) surface. That is not always bad.

I really meant bugs, as in: the code consciously takes advantage of
current behavior.  Those assumptions are only bad if we define them
that way.

> Yes, that is true. However the current behavior probably wastes a lot
> of time for those unaware of it.

Just like with programming with monitors where you're taught "always do
the wait within a `while' loop", regexp-patching should always take
place within a `if' or equivalent,


        Stefan

Previous Next

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