Re: --with-included-foo={yes,no} and which foo.h to use?

[Charles Levert]

* 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...