Re: Need some bug/version info

"Stephen J. Turnbull" <[email protected]>
Newsgroups gmane.emacs.auc-tex
Organization The XEmacs Project
Message-ID <[email protected]>
>>>>> "Ralf" == Ralf Angeli <[email protected]> writes:

    Ralf> * Stephen J. Turnbull (2005-02-02) writes:

    >>   (error 'invalid-state "XEmacs 21.4.16 (and only that release) has a
    >> fatal bug in the regexp code that AUCTeX triggers in several
    >> places.  Upgrade to 21.4.17."))

    >> in some appropriate place in the auctex load sequence is what I
    >> would suggest; even if AUCTeX works around it, other
    >> applications could trigger it.

    Ralf> That's pretty consequent.  Besides people building current
    Ralf> stable versions of XEmacs directly from xemacs.org, it would
    Ralf> currently lock out everybody facilitating a distribution
    Ralf> with a frequently updated package/port system, like
    Ralf> Debian/sid, Fedora Core Devel, Mandrake

Yah, well, I doubt they like coredumps any more than we do. You could
do

(when (and (featurep 'xemacs)
            (emacs-version>= 21 4 16)
            (not (emacs-version>= 21 4 17))
            (not auctex-user-likes-to-live-dangerously))

    Ralf> As David already indicated with his questions it doesn't
    Ralf> seem to be enough to [prime the registers] once per XEmacs
    Ralf> session.  At least it didn't work if included in tex-site.el.

No, that's definitely not good enough, because any regexp with enough
groups that succeeds will then set the registers to values that are
match-specific.  Therefore, unless those registers are cleared by
_every_ regexp match, it can cause Lisp errors and core dumps if
match-string et al are used to refer to different text later.  :-(
We've been through this on emacs-devel; the Emacs Lisp use of globals
for match-data is just insane IMO.

If you use a regexp with shy groups, then you are at risk if any
following code calls (match-string N) for num_nonshy_regs < N <=
num_regs before a match with num_nonshy_regs (for the second regexp)
>= num_regs (for the first regexp) succeeds.  (Of course
match-beginning and match-end also suffer from the bug.)

In correct code (IMHO, YMMV) this should only happen in code that
looks something like

(let ((re (pick-from list-of-regexps-some-of-which-have-N-capturing-groups)))
  ;; (match-string "x" "x") ; might win
  (re-search-forward re)
  (do-something-with (match-string N)))

I would guess that in AUCTeX you're iterating over sets of regexps in
a loop or something like that.  But finding them all?  Sounds icky.

    Ralf> I adapted the Reply-To to limit further discussion of this
    Ralf> issue to the AUCTeX list as this will probably not be of
    Ralf> high relevance for the XEmacs community.  Feel free to
    Ralf> ignore this if you think otherwise.

Well, I think from our point of view adding a "mea culpa, it's our
crash" to the FAQ and getting 21.4.17 out the door ASAP is the best we
can do.  So that's fine with me.  Feel free to come and consult if
something above inspires a good idea, though.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what y
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.