Hi Paul, * Paul Eggert wrote on Fri, May 19, 2006 at 11:04:52PM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > We check the 99 commands limit, but > > not the [4000] characters limit any more... :-/ > > But the 4000-character limit is documented by Autoconf to be a limit > on the length of lines of sed's input data, not a limit on the total > size of the sed script.
D'oh. I misread this section long ago and have always thought that wrongly since... So then the total limit of the script size I found on Solaris (described in that other mail in this thread that was pending for some hours) really is a new issue. > However, it turns out that we check the 99 commands limit incorrectly, > as the sed script in question contains 100 commands. I installed this > patch. It's conceivable that this patch fixes the problem; it'd be > nice to test this. All my testing of seds a couple of months ago showed that labels do not count as commands. If you have a sed where this is different, then I'd like to know. > I found what appear to be some other off-by-one issues that cause > 98-line scripts instead of 99, but these are not bugs so I didn't fix > it. Also, that code is too hairy (does anybody understand it other > than its author? I sure don't) so I didn't want to mess with it. It's pretty hairy. I don't want to claim that I fully understand it, but I did fix a couple of bugs in it. > In the long run we're probably better off finding a working 'sed' than > continuing to cater to broken ones. FWIW, I agree. Actually, it would probably be best to kill the quadratic complexity in the number of AC_SUBSTs incurred by a sed script and replace it by an awk script that searches for @[a-zA-Z][a-zA-Z0-9]*@ in the .in file and uses that variable name as key in a hash. Cheers, Ralf
