* bug#3863: 23.1.50; possible save-match-data in copyright.el
@ 2009-07-16 0:05 Kevin Ryde
2009-07-16 2:01 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Kevin Ryde @ 2009-07-16 0:05 UTC (permalink / raw
To: emacs-pretest-bug
[-- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 0:05 Kevin Ryde
@ 2009-07-16 2:01 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-07-16 2:01 UTC (permalink / raw
To: Kevin Ryde; +Cc: emacs-pretest-bug, 3863
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
@ 2009-07-16 14:33 Chong Yidong
2009-07-16 17:24 ` Stefan Monnier
2009-08-06 0:56 ` Kevin Ryde
0 siblings, 2 replies; 13+ messages in thread
From: Chong Yidong @ 2009-07-16 14:33 UTC (permalink / raw
To: Kevin Ryde; +Cc: 3863
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 14:33 bug#3863: 23.1.50; possible save-match-data in copyright.el Chong Yidong
@ 2009-07-16 17:24 ` Stefan Monnier
2009-07-16 18:42 ` Lennart Borgman
2009-07-16 18:54 ` Chong Yidong
2009-08-06 0:56 ` Kevin Ryde
1 sibling, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-07-16 17:24 UTC (permalink / raw
To: Chong Yidong; +Cc: 3863, Kevin Ryde
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 17:24 ` Stefan Monnier
@ 2009-07-16 18:42 ` Lennart Borgman
2009-07-17 3:23 ` Stefan Monnier
2009-07-16 18:54 ` Chong Yidong
1 sibling, 1 reply; 13+ messages in thread
From: Lennart Borgman @ 2009-07-16 18:42 UTC (permalink / raw
To: Stefan Monnier, 3863; +Cc: Chong Yidong, Kevin Ryde
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 17:24 ` Stefan Monnier
2009-07-16 18:42 ` Lennart Borgman
@ 2009-07-16 18:54 ` Chong Yidong
2009-07-17 3:24 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-07-16 18:54 UTC (permalink / raw
To: Stefan Monnier; +Cc: 3863, Kevin Ryde
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)?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 18:42 ` Lennart Borgman
@ 2009-07-17 3:23 ` Stefan Monnier
2009-07-17 4:00 ` Lennart Borgman
2009-07-17 7:57 ` martin rudalics
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-07-17 3:23 UTC (permalink / raw
To: Lennart Borgman; +Cc: 3863, Kevin Ryde, Chong Yidong
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 18:54 ` Chong Yidong
@ 2009-07-17 3:24 ` Stefan Monnier
2009-07-17 3:54 ` Chong Yidong
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-07-17 3:24 UTC (permalink / raw
To: Chong Yidong; +Cc: 3863, Kevin Ryde
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-17 3:24 ` Stefan Monnier
@ 2009-07-17 3:54 ` Chong Yidong
2009-07-17 16:00 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-07-17 3:54 UTC (permalink / raw
To: Stefan Monnier; +Cc: 3863, Kevin Ryde
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-17 3:23 ` Stefan Monnier
@ 2009-07-17 4:00 ` Lennart Borgman
2009-07-17 7:57 ` martin rudalics
1 sibling, 0 replies; 13+ messages in thread
From: Lennart Borgman @ 2009-07-17 4:00 UTC (permalink / raw
To: Stefan Monnier; +Cc: 3863, Kevin Ryde, Chong Yidong
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-17 3:23 ` Stefan Monnier
2009-07-17 4:00 ` Lennart Borgman
@ 2009-07-17 7:57 ` martin rudalics
1 sibling, 0 replies; 13+ messages in thread
From: martin rudalics @ 2009-07-17 7:57 UTC (permalink / raw
To: Stefan Monnier; +Cc: 3863
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-17 3:54 ` Chong Yidong
@ 2009-07-17 16:00 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-07-17 16:00 UTC (permalink / raw
To: Chong Yidong; +Cc: 3863, Kevin Ryde
>>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#3863: 23.1.50; possible save-match-data in copyright.el
2009-07-16 14:33 bug#3863: 23.1.50; possible save-match-data in copyright.el Chong Yidong
2009-07-16 17:24 ` Stefan Monnier
@ 2009-08-06 0:56 ` Kevin Ryde
1 sibling, 0 replies; 13+ messages in thread
From: Kevin Ryde @ 2009-08-06 0:56 UTC (permalink / raw
To: Chong Yidong; +Cc: 3863
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-08-06 0:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-16 14:33 bug#3863: 23.1.50; possible save-match-data in copyright.el Chong Yidong
2009-07-16 17:24 ` Stefan Monnier
2009-07-16 18:42 ` Lennart Borgman
2009-07-17 3:23 ` Stefan Monnier
2009-07-17 4:00 ` Lennart Borgman
2009-07-17 7:57 ` martin rudalics
2009-07-16 18:54 ` Chong Yidong
2009-07-17 3:24 ` Stefan Monnier
2009-07-17 3:54 ` Chong Yidong
2009-07-17 16:00 ` Stefan Monnier
2009-08-06 0:56 ` Kevin Ryde
-- strict thread matches above, loose matches on Subject: below --
2009-07-16 0:05 Kevin Ryde
2009-07-16 2:01 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.