[redirected to people apparently working on SRE]
On Mon, 21 Apr 2003, Tim Peters wrote:
> Narrowing it down to the specific C code that's at fault is still the best
> hope. There are two reasons for that:
>
> 1. It's very easy to write ill-defined code in C, and for all we know
> now some part of _sre is depending on undefined, or implementation
> defined (but apparently likely), behavior.
>
> 2. If that's not the problem, optimization bugs are usually easy to
> sidestep via minor code changes. You have to know which code is
> getting screwed first, though.
Seeing that Gustavo had checked in some changes to _sre.c on Sunday, I CVS
up'ed and now find that a gcc 2.95.4 build survives test_sre with -O3.
A gcc 3.2.2 build still gets a bus error with either -O3 or -O2.
The actual test case from test_sre that fails is:
---8<---8<---
# non-simple '*?' still recurses and hits the recursion limit
test(r"""sre.search('(a|b)*?c', 10000*'ab'+'cd').end(0)""", None, RuntimeError)
---8<---8<---
For the moment, the FreeBSD 5.x (ie gcc 3.2.x) element of my configure.in
patch (SF #725024) is still valid.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370
andymac@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4