On Thu, Aug 26, 2004 at 11:25:01AM -0400, Harry Pulley wrote: > Hi Steve, > > It's been nearly two years since I sent this bug report but I do still > believe it is a bug. That code didn't hang long ago but has now been > hanging for the last couple of released versions. The test code snippet > was culled from a big problem one of our customers was having. That > customer certainly considers it a bug but I wasn't involved until final > developer level support so I didn't have the opportunity to ask them why > they were using that particular regular expression syntax, only to > confirm that it used to work in an earlier perl port but started to fail > in our 5.6 port. Although the behavior did change with 5.6, this is nonetheless a bug in the code, not in perl. while ($procName =~ /\G([\w]+)|([\s]+)|([^\w\x]+)/g) There are two problems with this regex. One is the use of \x. \x indicates a hexdecimal character specification, e.g. \x20 is space. \x must be followed by at least one hexadecimal digit, so \x] is clearly an error. I presume that this was a typo for \s, so that the third alternative matches whatever the first two don't. The other problem is that \G is only part of the first alternative. While this would work in older versions of perl, somewhere along the way the meaning of \G changed. Now, if \G is present, the regex can attempt to match before the value of pos(). This means that the second and third alternatives above, which don't include \G, are free to match the same part of the string over and over again. It was basically a coincidence that the original regex happened to work in older versions of perl. A correct regex would be: while ($procName =~ /\G(?:([\w]+)|([\s]+)|([^\w\s]+))/g) HTH, RonaldThread Previous | Thread Next