Conor,
> A bit more detail here, it has been narrowed down to 2 regex lines in
> magic.
Thanks!
Here are two replacement lines to the magic file
that limit the RE evaluation time on Linux,
and produce comparable results.
100 regex/c =^[\ \t]{0,999}call[\ \t]{1,999}rxfu OS/2 REXX batch file text
100 regex/c =^[[:space:]]{0,999}say\ ['"] OS/2 REXX batch file text
The following is what I sent to Christos, and will be accepted for the
next version:
| > Well, the regex stuff on later versions of linux seems to be the
| > culprit:
|
| Perhaps. Still, using more than one wildcard in a regular expression
| on a possibly long string is asking for trouble - it depends on
| how well the optimizer in a regex library does its job, and if
| unlucky, one could end up in a deep recursion or with O(2+) searches.
| It needn't be a bug and can still result in unacceptable behaviour.
|
| It is prudent to limit the allowed range of matches in a regular
| expression as much as possible and practical.
|
| The following replacement entries in a magic file are functionally
| pretty close to existing expressions, but are safe to use,
| even on Linux:
|
| 100 regex/c =^[\ \t]{0,999}call[\ \t]{1,999}rxfu OS/2 REXX batch file text
| 100 regex/c =^[[:space:]]{0,999}say\ ['"] OS/2 REXX batch file text
|
| I had to shrink the first one, as the length of a RE is severely limited
| by a magic file.
|
| I also avoided the \s, which is not documented in POSIX regex,
| and is possibly also a reason why the problem does not occur on Solaris.
Mark
|
