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

Previous Next

Full log

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.

Previous Next

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