A small fix for bug #545855 and  Greg Chapman's 
addition of op code SRE_OP_MIN_REPEAT_ONE for 
eliminating recursion on simple uses of pattern '*?' on a 
long string. 

Logged In: YES 
user_id=6380

Will look at this ASAP.

Logged In: YES 
user_id=6380

Looks cool; I've checked this in unchanged, except changing
one comment: the comment about the test for bug 545855 said
it would generate errors during matching, while when I try
it, the pattern generates a TypeError during compilation. I
don't feel capable to review the code you added to _sre.c;
I'll assign it to Fredrik, but I don't expect him to have
time to look at it. It seems you haven't broken his
requirement for this code to work back to Python 1.5.2. I'll
backport to Python 2.2 as well.

Do I understand correctly that the .*? addition is all Greg
Chapman's work?

Logged In: YES 
user_id=6380

Gary, I wonder if you could rework your fix for Python 2.2?
The patch doesn't apply cleanly there; one of the problems
is that lastmark_restore() doesn't exist. I wonder if maybe
all of the _sre.c code should simply be copied to the 2.2
branch?

Logged In: YES 
user_id=395736

Sure, I'll port it to Python2.2.  I'm surprised it dod not apply 
cleanly there, but then I don't know the history of previous 
patches (like when lastmark_restore was introduced).  I guess 
copying all sre code will be the first thing to try.  How do I get a 
dev version of Python 2.2? 
 
Yes, the *? code is all Greg Chapman's.  He sent it to me the day 
I announced my volunteering to maintain the sre code.  I wrote 
the test cases for it, and used it as a great way to learn my way 
through the code. 

Logged In: YES 
user_id=6380

The Python 2.2 maintenance branch is labeled with the CVS
tag 'release22-maint'. I hope you know or can find out about
working with CVS branches. Good luck!

Logged In: YES 
user_id=395736

I copied all the (8) sre files from  the 2.3 branch to the 
release22-maint branch and compiled and ran the test.  It 
worked flawlessly with the single exception that module init 
functions are declared as type 
  DL_EXPORT(void) -- in 2.2 
and as type 
  PyMODINIT_FUNC -- in 2.3 
 
If there are no considerations other than getting the tests to run 
successfully, then I'll declare success and produce a patch and 
submit it. OK? 
 
 

Logged In: YES 
user_id=6380

Great! Sounds like a plan.

Logged In: YES 
user_id=250749

This patch has made _sre.c more susceptible to optimisation
breakage.

The default autoconf optimisation setting for gcc is -O3. 
When _sre.c is so compiled with gcc 2.95.[34] on FreeBSD
4.[47] and gcc 3.2.1 on OS/2+EMX with this level of
optimisation, I get a bus error (sig 10) when running
test_sre (a SYS3171 on OS/2, which is the same thing).

The bus error is not evident with -O2 for gcc 2.95.[34], or
-O for gcc 3.2.1.

Unfortunately I don't have any recent version of gcc
(3.[12].x) available on FreeBSD yet to evaluate.

I have no idea how to introduce a special optimisation
setting just for _sre.c in autoconf, but lowering the
optimisation for all other files seems a major backward step
if its -O3 -> -O; dropping everything from -O3 to -O2 would
be tolerable I think.

As I'm not using autoconf on OS/2, dealing with this is not
a problem there.

Logged In: YES 
user_id=7887

Gary, have you backported the 2.3 _sre.c to 2.2? If so, we
must backport it again, since there are important fixes
relative to 2.2 code, and relative to code introduced in 2.3.

Logged In: YES 
user_id=86307

Andrew, I used some block-scoped locals in the 
MIN_REPEAT_ONE branch (matchmax and c).  I wonder if 
removing those would fix the optimization problem.  I have a 
patch against the latest CVS version (2.91) which I can send 
you if you'd like.  (The patch just moves the test for 65535 
into the while statement and reuses i to hold the result of 
SRE_COUNT).

Logged In: YES 
user_id=33168

Bug 545855 is fixed.  The test cases from this patch seem to
work fine, so I'm closing.