* On Thursday 2005-07-07 at 14:01:32 +0200, Stepan Kasal wrote: > > On Thu, Jul 07, 2005 at 02:33:59AM -0400, Charles Levert wrote: > > > > But there's a catch-22 here. See below. > > I don't understand exactly why the number is 22...
If you're serious and not joking here, it's a popular expression meaning a chicken-and-egg problem. It's the title of a famous book that you can Google for. It's also a military term. It's not from my own culture, though (I'm not USA-"American" but French-Canadian-"American"). > > Updating to glibc's regex.c will allow us to > > progress in fixing RE_ICASE bugs now, and maybe > > others as well. That why I can't see one being > > a priority without the other. > > Well, it's obvious that with the old regex.c we cannot fully fix all > the icase problems. We can just fix the most obvious. My point-of-view here is that any time spent trying to back-port changes/fixes to a much different old regex.c is just a waste of our time. Having to understand the current glibc regex.c is plenty enough. > Full icase fix is tied to new regex. > > But there is no need to fix _all_ problems in the _next_ release. True, but what's more work in the end (with regard to upgrading to the newest regex.c)? Your comment only has an implication if sticking with the old regex.c, while fixing it, is what would require the least amount of work. Otherwise, it's moot. > I wanted to create an improved version of 2.5.1, which would be ready > for people which for some reason cannot use the new regex.c. > (Perhaps the new regex won't compile on an ancient platform, or they > will have to use a regex which shows the inefficiency of the new > regex, perhaps something like the original palindrome regex, which > takes ages to run with new regex.) That is a real concern, which is why I encourage wide testing of the bold approach now, to highlight problems that may force a back-down. You obviously know more than I do about these specific performance issues. Do you have some tests we could time(1)? > So my opinion still is that it would be better to release what we have > now as 2.5.2, no matter how many bugs are remaining. Ok. Let Julian commit the pending src/kwset.c fix and let's do that right away then. (I still don't understand the second test case, but I think the fix is correct nevertheless. Please don't use a MIN() macro with a complex twice-evaluated argument that the optimizer might not pick up on, though; see a previous email for my proposed alternative.) Maybe with grep.1 requested fixes, too; later in the day...
