bug#3863: 23.1.50; possible save-match-data in copyright.el

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

In recent copyright.el I noticed copyright-update using the match data
after a y-or-n-p query.  Is that a good idea?

When running it in emacs 22 I seemed to sometimes get the match data
clobbered by y-or-n-p.  I never tracked down the circumstances, but
wondered if copyright.el shouldn't rely on what an input func like
y-or-n-p could do, per diff below.


In GNU Emacs 23.1.50.1 (i586-pc-linux-gnu, GTK+ Version 2.16.4)
 of 2009-07-12 on blah.blah
configured using `configure  'CFLAGS=-O -g' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t


2009-07-16  Kevin Ryde  <user42@zip.com.au>

	* emacs-lisp/copyright.el (copyright-update): save-match-data across
	y-or-n-p, for safety.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: copyright.el.save-match-data.diff --]
[-- Type: text/x-diff, Size: 917 bytes --]

*** copyright.el	16 Jul 2009 09:44:20 +1000	1.81
--- copyright.el	16 Jul 2009 09:55:57 +1000	
***************
*** 223,230 ****
                 (< (string-to-number (match-string 3))
                    (string-to-number copyright-current-gpl-version))
  	       (or noquery
! 		   (y-or-n-p (format "Replace GPL version by %s? "
! 				     copyright-current-gpl-version)))
  	       (progn
  		 (if (match-end 2)
  		     ;; Esperanto bilingual comment in two-column.el
--- 223,231 ----
                 (< (string-to-number (match-string 3))
                    (string-to-number copyright-current-gpl-version))
  	       (or noquery
!                    (save-match-data
!                      (y-or-n-p (format "Replace GPL version by %s? "
!                                        copyright-current-gpl-version))))
  	       (progn
  		 (if (match-end 2)
  		     ;; Esperanto bilingual comment in two-column.el

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Stefan Monnier]

> 2009-07-16  Kevin Ryde  <user42@zip.com.au>

> 	* emacs-lisp/copyright.el (copyright-update): save-match-data across
> 	y-or-n-p, for safety.

Thanks, installed,


        Stefan

bug#3863: marked as done (23.1.50; possible save-match-data in copyright.el)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

Your message dated Fri, 02 Oct 2009 10:14:07 +1000
with message-id <87fxa27iuo.fsf@blah.blah>
and subject line Re: bug#3863: 23.1.50; possible save-match-data in copyright.el
has caused the Emacs bug report #3863,
regarding 23.1.50; possible save-match-data in copyright.el
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3863: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3863
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4412 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1034 bytes --]

In recent copyright.el I noticed copyright-update using the match data
after a y-or-n-p query.  Is that a good idea?

When running it in emacs 22 I seemed to sometimes get the match data
clobbered by y-or-n-p.  I never tracked down the circumstances, but
wondered if copyright.el shouldn't rely on what an input func like
y-or-n-p could do, per diff below.


In GNU Emacs 23.1.50.1 (i586-pc-linux-gnu, GTK+ Version 2.16.4)
 of 2009-07-12 on blah.blah
configured using `configure  'CFLAGS=-O -g' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t


2009-07-16  Kevin Ryde  <user42@zip.com.au>

	* emacs-lisp/copyright.el (copyright-update): save-match-data across
	y-or-n-p, for safety.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1.2: copyright.el.save-match-data.diff --]
[-- Type: text/x-diff, Size: 917 bytes --]

*** copyright.el	16 Jul 2009 09:44:20 +1000	1.81
--- copyright.el	16 Jul 2009 09:55:57 +1000	
***************
*** 223,230 ****
                 (< (string-to-number (match-string 3))
                    (string-to-number copyright-current-gpl-version))
  	       (or noquery
! 		   (y-or-n-p (format "Replace GPL version by %s? "
! 				     copyright-current-gpl-version)))
  	       (progn
  		 (if (match-end 2)
  		     ;; Esperanto bilingual comment in two-column.el
--- 223,231 ----
                 (< (string-to-number (match-string 3))
                    (string-to-number copyright-current-gpl-version))
  	       (or noquery
!                    (save-match-data
!                      (y-or-n-p (format "Replace GPL version by %s? "
!                                        copyright-current-gpl-version))))
  	       (progn
  		 (if (match-end 2)
  		     ;; Esperanto bilingual comment in two-column.el

[-- Attachment #3: Type: message/rfc822, Size: 1938 bytes --]

From: Kevin Ryde <user42@zip.com.au>
To: 3863-done@emacsbugs.donarmstrong.com
Subject: Re: bug#3863: 23.1.50; possible save-match-data in copyright.el
Date: Fri, 02 Oct 2009 10:14:07 +1000
Message-ID: <87fxa27iuo.fsf@blah.blah>

Closing for,

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> installed,

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Chong Yidong]

> In recent copyright.el I noticed copyright-update using the match data
> after a y-or-n-p query.  Is that a good idea?
>
> When running it in emacs 22 I seemed to sometimes get the match data
> clobbered by y-or-n-p.

If so, we should change y-or-n-p to save the match data.  Could you
provide a reproducible test-case for the clobbering of the match data?

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Stefan Monnier]

> If so, we should change y-or-n-p to save the match data.

Why?  y-or-n-p will yield waiting for user input, so it's basically
a point where any other code can run.  It's one of the prime examples of
a function which you can't expect to preserve the match-data.


        Stefan

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Lennart Borgman]

On Thu, Jul 16, 2009 at 7:24 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>> If so, we should change y-or-n-p to save the match data.
>
> Why?  y-or-n-p will yield waiting for user input, so it's basically
> a point where any other code can run.  It's one of the prime examples of
> a function which you can't expect to preserve the match-data.

I don't think I understand, but it sounds like this is a reason why
y-or-n-p should save match-data...

Is there any reason not to let y-or-n-p save match data? I mean the
function needing match data possibly want yield until it has used it,
or?

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Stefan Monnier]

> I don't think I understand, but it sounds like this is a reason why
> y-or-n-p should save match-data...

Here we go again:

All functions destroy the match-data except for a few rare exceptions,
which are simple functions doing little work.

> Is there any reason not to let y-or-n-p save match data?

If you think y-or-n-p deserves saving the match-data then pretty much
all other functions deserve that change as well.  And since
save-match-data is somewhat costly, it would imply a singificant
performance impact.


        Stefan


PS: Worse yet: during y-or-n-p, the buffer might be completely changed
by the code run asynchronously, so the "saved" match data may not even
have any meaning any more.

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Lennart Borgman]

On Fri, Jul 17, 2009 at 5:23 AM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>> I don't think I understand, but it sounds like this is a reason why
>> y-or-n-p should save match-data...
>
> Here we go again:
>
> All functions destroy the match-data except for a few rare exceptions,
> which are simple functions doing little work.
>
>> Is there any reason not to let y-or-n-p save match data?
>
> If you think y-or-n-p deserves saving the match-data then pretty much
> all other functions deserve that change as well.  And since
> save-match-data is somewhat costly, it would imply a singificant
> performance impact.

Sorry, I just meant that since the functions that prompts the user
can't really impact performance if we just add save-match-data to them
we could do that just to get some more protection.

It does not cure the problem that some functions running in timers
forgets to save match data, but perhaps it catches some actually
occuring problem cases.

bug#3863: 23.1.50; possible save-match-data in copyright.el

[martin rudalics]

 > If you think y-or-n-p deserves saving the match-data then pretty much
 > all other functions deserve that change as well.  And since
 > save-match-data is somewhat costly, it would imply a singificant
 > performance impact.

You're obviously right and I meanwhile also learned to share your
earlier reservations wrt `looking-at-p' and `string-match-p'.  However,
the underlying problem deserves a profound explanation in the Elisp
manual in oder to avoid such discussions in the future.  So please,
pretty please, write one.

martin

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Why?  y-or-n-p will yield waiting for user input, so it's basically
> a point where any other code can run.  It's one of the prime examples of
> a function which you can't expect to preserve the match-data.

I'm not sure what you're referring to.  What other code runs during
y-or-n-p (excluding timers, which are supposed to save the match data)?

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Stefan Monnier]

> I'm not sure what you're referring to.  What other code runs during
> y-or-n-p (excluding timers, which are supposed to save the match data)?

Timers,


        Stefan

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm not sure what you're referring to.  What other code runs during
>> y-or-n-p (excluding timers, which are supposed to save the match data)?
>
> Timers,

As the Lisp manual states,

     If a timer function calls functions that can change the match data,
  it should save and restore the match data.

If a timer fails to do this, it's a bug, and should be fixed.

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Stefan Monnier]

>>> I'm not sure what you're referring to.  What other code runs during
>>> y-or-n-p (excluding timers, which are supposed to save the match data)?
>> 
>> Timers,

> As the Lisp manual states,

>      If a timer function calls functions that can change the match data,
>   it should save and restore the match data.

> If a timer fails to do this, it's a bug, and should be fixed.

Wonderful, so we all agree there's no need to make y-or-n-p save the
match-data.


        Stefan

bug#3863: 23.1.50; possible save-match-data in copyright.el

[Kevin Ryde]

Chong Yidong <cyd@stupidchicken.com> writes:
>
> Could you
> provide a reproducible test-case for the clobbering of the match data?

When I struck it, which is a while ago now, it was intermittent.  It
could even have been some of my own input defadvice stuff, though I
thought it wasn't.